Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Number of callers to install_displaced_markword_in_object() has changed. Also make updates to the hashcode section.

...

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.

...

  1. 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.
  2. There are several reasons why we might have to inflate the ObjectMonitor in order to set the hashcode:
    1. 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.
    2. The object is stack locked and does not contain a hashcode in the mark word.
    3. 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.

...