3 ms·

Isn't just the lock something that potentially needs space per object?

by ygra 2y ago

guipsp 2y ago
You can lock on any object - if you dynamically create these locks, then you need to coordinate creation among threads.
- masklinn 2y ago
  They're saying that only the lock should need storage in the object header, everything else can be computed on the fly (obviously at a CPU cost rather than memory). Equality is computed (and the default is trivial, it just compares addresses), hashcode is computed (and the default is trivial, it just returns the object's address), string conversion is computed (and the default is trivial, it just prints the class name and the hashcode IIRC).
  - _old_dude_ 2y ago
    > the default is trivial, it just returns the object's address This was trivial a long time ago. Now, all Java GCs move objects in memory.
  - greiskul 2y ago
    I'm not sure you can just return the object address for hashcode, because with GC the object address can move right? So if you are using it for hashcode, you do need to persist it somewhere after it's called the first time.
    - Nevermark 2y ago
      Would an optional "Hashable" class interface be a good way to reduce the classes (and objects) that need to have a hash? Or is having a hash an unavoidable primitive feature? Also, would an optional "Lockable" class interface be a good way to drastically reduce the classes (and objects) that need to maintain lock information? I am religiously averse to unused but implemented "Positive-Cost Abstractions". I dream of a root class with no methods except "new", and instance methods delete() and isSelf(x). Even "Polymorphism" could be an opt-in interface. Subclasses of non-polymorphic classes would inherit functionality (yay, reusability), but not be a subtype of their root class. (With commutativity between subclassing & the polymorphic interface. I.e. If A is a non-polymorphic class, and Ap is a polymorphic version of class A, then all subclasses of Ap and all polymorphic subclasses of A, would be subtypes of Ap.)
layer8 2y ago
Object::hashCode returns System.identityHashCode(Object) by default. Since GC can move objects around in memory, and the hash code of an object needs to be stable, this default hash code can’t be based on the memory address of the object, and thus needs to be stored per object. Since System.identityHashCode() can be invoked (for example by IdentityHashMap) even for objects of classes that implement a custom hash code, it also can’t be optimized away even for such classes. Conceivably it could be optimized away for an object unless or until System.identityHashCode() is invoked for it. It could thus be allocated on demand similarly to how the object locks are. Of course, this has all kinds of performance trade-offs.

Isn't just the lock something that potentially needs space per object?

by ygra 2y ago

Isn't just the lock something that potentially needs space per object?

guipsp 2y ago

You can lock on any object - if you dynamically create these locks, then you need to coordinate creation among threads.

masklinn 2y ago
They're saying that only the lock should need storage in the object header, everything else can be computed on the fly (obviously at a CPU cost rather than memory). Equality is computed (and the default is trivial, it just compares addresses), hashcode is computed (and the default is trivial, it just returns the object's address), string conversion is computed (and the default is trivial, it just prints the class name and the hashcode IIRC).
- _old_dude_ 2y ago
  > the default is trivial, it just returns the object's address This was trivial a long time ago. Now, all Java GCs move objects in memory.
- greiskul 2y ago
  I'm not sure you can just return the object address for hashcode, because with GC the object address can move right? So if you are using it for hashcode, you do need to persist it somewhere after it's called the first time.
  - Nevermark 2y ago
    Would an optional "Hashable" class interface be a good way to reduce the classes (and objects) that need to have a hash? Or is having a hash an unavoidable primitive feature? Also, would an optional "Lockable" class interface be a good way to drastically reduce the classes (and objects) that need to maintain lock information? I am religiously averse to unused but implemented "Positive-Cost Abstractions". I dream of a root class with no methods except "new", and instance methods delete() and isSelf(x). Even "Polymorphism" could be an opt-in interface. Subclasses of non-polymorphic classes would inherit functionality (yay, reusability), but not be a subtype of their root class. (With commutativity between subclassing & the polymorphic interface. I.e. If A is a non-polymorphic class, and Ap is a polymorphic version of class A, then all subclasses of Ap and all polymorphic subclasses of A, would be subtypes of Ap.)

layer8 2y ago

Object::hashCode returns System.identityHashCode(Object) by default. Since GC can move objects around in memory, and the hash code of an object needs to be stable, this default hash code can’t be based on the memory address of the object, and thus needs to be stored per object. Since System.identityHashCode() can be invoked (for example by IdentityHashMap) even for objects of classes that implement a custom hash code, it also can’t be optimized away even for such classes. Conceivably it could be optimized away for an object unless or until System.identityHashCode() is invoked for it. It could thus be allocated on demand similarly to how the object locks are. Of course, this has all kinds of performance trade-offs.