Where is object's hash code stored if biased-locking is enabled in HotSpot JVM?

Question

As far as I know an object's hash code is normally stored in the header word of the object, which, for example, may have the following layout in HotSpot:

|  hash code  | age | 0 | 01 |

According to the HotSpotInternals - Synchronization with biased locking enabled the header word layout looks in the following way:

|   0   |epoch| age | 0 | 01 |

Where does the hash code is then actually stored if needed when biased locking is enabled?

Aurel

Answer 1

My understanding is that asking for the (identity) hashcode prevents biased locking - as we cannot store both the hashcode and thread id in the mark word. If you ask for the hashcode of the mutex you transfer to unbiased locking mode.

This is supported by the following taken from this blog:

"Finally, there's not currently space in the mark word to support both an identity hashCode() value as well as the thread ID needed for the biased locking encoding. Given that, you can avoid biased locking on a per-object basis by calling System.identityHashCode(o). If the object is already biased, assigning an identity hashCode will result in revocation, otherwise, the assignment of a hashCode() will make the object ineligible for subsequent biased locking. This property is an artifact of our current implementation, of course."

Fatherly

This seems to be the case at least in OpenJDK looking at the source code: hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/87ee5ee27509/src/… – Oneil

This problem will disappear as biased locking is being disabled and removed in JDK 15: openjdk.java.net/jeps/374 – Heighten