Menu
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?
289
Biased locking is an optimization to enable very fast syn- chronization in the Java virtual machine. It is based on the observation that many times objects are not shared between threads, and could therefore avoid the slower and otherwise necessary atomic instructions for synchronization.
The value returned by hashCode() is by no means guaranteed to be the memory address of the object. According to Java API, the calculation of hashcode is based on 32-bit internal JVM (Java Virtual Machine) address of the Object. It is true that the object moves during execution. But hashcode does not change.
In Java, hashCode() by default is a native method, which means that the method has a modifier 'native', when it is implemented directly in the native code in the JVM. Used to digest all the data stored in an instance of the class into a single hash value i.e., a 32-bit signed integer.
By default the hashCode() returns an integer that represents the internal memory address of the object. Where this comes in handy is in the creation and use of an important computer science data structure called a hash table.
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 callingSystem.identityHashCode(o). If the object is already biased, assigning an identity hashCode will result in revocation, otherwise, the assignment of ahashCode()will make the object ineligible for subsequent biased locking. This property is an artifact of our current implementation, of course."
81
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
