...
ObjectMonitor::install_displaced_markword_in_object() is the new piece of code that handles all the racy situations with restoring an object's header asynchronously. The function is called from two three places (deflation and , ObjectMonitor::enter(), and FastHashCode). Only one of the possible racing scenarios can win and the losing scenarios all adapt to the winning scenario's object header value.
...
- If the object has an ObjectMonitor (i.e., is inflated) and if the ObjectMonitor has a hashcode, then the hashcode value can be safely carefully fetched from the ObjectMonitor and returned to the caller (T-hash). The first stage of a racing async deflation (by T-deflate) won't affect the hashcode value that is stored in an ObjectMonitor, i.e., the race is benignIf there is a race with async deflation, then we have to retry.
- There are several reasons why we might have to inflate the ObjectMonitor in order to set the hashcode:
- The object is neutral, does not contain a hashcode and we (T-hash) lost the race to try an install a hashcode in the mark word.
- The object is stack locked and does not contain a hashcode in the mark word.
- The object has an ObjectMonitor and the ObjectMonitor does not have a hashcode.
Note: In this case, the inflate() call on the common fall thru code path is almost always a no-op since the existing ObjectMonitor is not likely to be async deflated before inflate() sees that the object already has an ObjectMonitor and bails out.
...