Page History

...

• When System.identityHashCode() is first called on an object and as long as the object is not moved in memory (by the GC), its i-hash gets computed and returned to the caller. In order to do this, we need to provide a new idempotent hash-code function based on the memory address of the object, because the current hash-code function essentially returns a new random number for each invocation.
• As soon as the GC moves the object to a new location, the i-hash needs to be preserved, so that future calls of System.identityHashCode() can return the same i-hash (hash-code stability is a crucial part of the contract between JVM and user code). In order to do this, GCs will allocate an extra word for the new copy of the object (if necessary, see below), and store the i-hash into an appended hidden field following all existing fields of the object/array. From that point onwards, calls to System.identityHashCode() returns the stored i-hash.
• Many objects have an alignment gap somewhere in the field layout, or at the end of the object. If the alignment gap is large enough (that is, at least 4 bytes), then the i-hash can be stored into that gap immediately and GCs don't have to expand the object.

...

• 00: The object has not yet been i-hashed. This is the default state.
• 01: The object has been i-hashed, but has not yet been moved from its original location in memory. The first call to System.identityHashCode() transitions the hash-bits from the 00 state to the 01 state, if there is no sufficient alignment gap at the end of the object, and return the computed i-hash. Subsequent calls of System.identityHashCode() will also re-compute and return the same i-hash (as long as the object stays at the same address, that is, as long as the object remains in the 01 state).
• 10: The object has been i-hashed and the i-hash has been stored in a hidden at the end of the object. The first call to System.identityHashCode() transitions the hash-bits from the 00 state to the 10 state, when there is sufficient alignment gap at the end of the object, and computes, stores and returns the i-hash in that hidden field. Also, GCs which observe the 01 hash-state in an object that needs to be moved to a new memory location, need to allocate an extra word in the object's new copy, and recompute the i-hash (from the object's original location) and store the i-hash into the hidden field in the extra word. Calls to System.identityHashCode() that observe the 10 state will always load and return the stored i-hash.

...