Page History

...

RFE: 8153224 Monitor deflation prolong safepoints
         https://bugs.openjdk.java.net/browse/JDK-8153224

Full Webrev: 17-for-jdk15+24.v2.1415.full

Inc Webrev: 17-for-jdk15+24.v2.1415.inc

Background

This patch for Async Monitor Deflation is based on Carsten Varming's

...

The current idle monitor deflation mechanism executes at a safepoint during cleanup operations. Due to this execution environment, the current mechanism does not have to worry about interference from concurrently executing JavaThreads. Async Monitor Deflation uses the ServiceThread to deflate idle monitors so the new mechanism has to detect interference and adapt as appropriate. In other words, data races are natural part of Async Monitor Deflation and the algorithms have to detect the races and react without data loss or corruption.

Async Monitor Deflation is performed in two stages: stage one performs the two part protocol described in "Deflation With Interference Detection" below and moves the async deflated ObjectMonitors from an in-use list to a global wait list; the ServiceThread performs a handshake (or a safepoint) with all other JavaThreads after stage one is complete and that forces any racing threads to make forward progress; stage two moves the ObjectMonitors from the global wait list to the global free list. The special values that mark an ObjectMonitor as async deflated remain in their fields until the ObjectMonitor is moved from the global free list to a per-thread free list which is sometime after stage two has completed.

Key Parts of the Algorithm

...

Once we know it is safe to deflate the monitor (which is mostly field resetting and monitor list management), we have to restore the object's header. That's another racy operation that is described below in "Restoring the Header With Interference Detection".

The setting of the special values that mark an ObjectMonitor as async deflated and the restoration of the object's header comprise the first stage of Async Monitor Deflation.

2) Restoring the Header With Interference Detection

...

• • This diagram starts after "Racing Threads".
  • The "1>" markers are showing where each thread is at for the ObjectMonitor box:
    
    • T-enter and T-deflate both observe a contentions field > 0.
  • T-enter has won the race and it continues with the contended enter protocol.
  • T-deflate detects that it has lost the race (prev != 0) and bails out on deflating the ObjectMonitor:
    
    • Before bailing out T-deflate tries to restore the owner field to NULL if it is still DEFLATER_MARKER.
  • The "2>" markers are showing where each thread is at for that ObjectMonitor box.
  • Note: The owner == DEFLATER_MARKER and contentions < 0 values that are set by T-deflate (stage one of async deflation) remain in place until after T-deflate does a handshake (or safepoint) operation with all JavaThreads. This handshake forces T-enter to make forward progress and see that the ObjectMonitor is being async deflated before T-enter checks in for the handshake.

...