Page History

...

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

Full Webrev: http://cr.openjdk.java.net/~dcubed/8153224-webrev/78-for-jdk13.full/

Inc Webrev: http://cr.openjdk.java.net/~dcubed/8153224-webrev/78-for-jdk13.inc/

Background

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

...

• • This diagram starts after "Racing Threads".
  • The "1>" markers are showing where each thread is at for that ObjectMonitor box:
    
    • T-save and T-deflate both observe owner == DEFLATER_MARKER and a negative ref_count field.
  • T-save has lost the race: it restores the obj header (not shown) and decrements the ref_count.
  • T-deflate restores the obj header (not shown).
  • The "2>" markers are showing where each thread is at for that ObjectMonitor box.
  • T-save returns false to cause the caller to retry.
  • T-deflate finishes the deflation.
  • Note: As of CR5/v2.05/8-for-jdk13, the owner == DEFLATER_MARKER value is allowed to linger until a deflated ObjectMonitor is reused for an enter operation. This prevents the C2 ObjectMonitor enter optimization from racing with async deflation.

T-save Wins

    T-save                             ObjectMonitor              T-deflate
    ---------------------------------  +-----------------------+  ------------------------------------------
    save_om_ptr() {                    | owner=DEFLATER_MARKER |  deflate_monitor_using_JT() {
      atomic inc ref_count             | ref_count=1           |    cmpxchg(DEFLATER_MARKER, &owner, NULL)
   1> if (owner == DEFLATER_MARKER &&  +-----------------------+    :
          ref_count <= 0) {                       ||                prev = cmpxchg(-max_jint, &ref_count, 0)
    } else {                                      \/               1> if (prev == 0 &&
      save om_ptr in the               +-----------------------+          owner == DEFLATER_MARKER) {
        ObjectMonitorHandle            | owner=NULL            |    } else {
   2> return true                      | ref_count=1           |      cmpxchg(NULL, &owner, DEFLATER_MARKER)
                                       +-----------------------+   2> return

...

• If MonitorUsedDeflationThreshold is exceeded (default is 90%, 0 means off), then the ServiceThread will invoke a cleanup safepoint.
  • This experimental flag was added in JDK10 via:

...

• Counterpart function mapping for those that know the existing code:
  • ObjectSynchronizer class:
    • deflate_idle_monitors() has deflate_global_idle_monitors_using_JT(), deflate_per_thread_idle_monitors_using_JT(), and deflate_common_idle_monitors_using_JT().
    • deflate_monitor_list() has deflate_monitor_list_using_JT()
    • deflate_monitor() has deflate_monitor_using_JT()
  • ObjectMonitor class:
    
    • is_busy() has is_busy_async()
    • clear() has clear_using_JT()
• These functions recognize the Async Monitor Deflation protocol and adapt their operations:
  
  • ObjectMonitor::enter()
  • ObjectMonitor::EnterI()
  • ObjectMonitor::ReenterI()
  • ObjectSynchronizer::quick_enter()
  • ObjectSynchronizer::deflate_monitor()
  • Note: These changes include handling the lingering owner == DEFLATER_MARKER value.
• Also these functions had to adapt and retry their operations:
  ObjectSynchronizer::quick_enter()
  
  • ObjectSynchronizer::FastHashCode()
  • ObjectSynchronizer::current_thread_holds_lock()
  • ObjectSynchronizer::query_lock_ownership()
  • ObjectSynchronizer::get_lock_owner()
  • ObjectSynchronizer::monitors_iterate()
  • ObjectSynchronizer::inflate_helper()
  • ObjectSynchronizer::inflate() 
• Various assertions had to be modified to pass without their real check when AsyncDeflateIdleMonitors is true; this is due to the change in semantics for the ObjectMonitor owner field.
• ObjectMonitor has a new allocation_state field that supports three states: 'Free', 'New', 'Old'. Async Monitor Deflation is only applied to ObjectMonitors that have reached the 'Old' state.
  • Note: Prior to CR1/v2.01/4-for-jdk13, the allocation state was transitioned from 'New' to 'Old' in deflate_monitor_via_JT(). This meant that deflate_monitor_via_JT() had to see an ObjectMonitor twice before deflating it. This policy was intended to prevent oscillation from 'New' → 'Old' and back again.
  • In CR1/v2.01/4-for-jdk13, the allocation state is transitioned from 'New' -> "Old" in inflate(). This makes ObjectMonitors available for deflation earlier. So far there has been no signs of oscillation from 'New' → 'Old' and back again.
• ObjectMonitor has a new ref_count field that is used as part of the async deflation protocol and to indicate that an ObjectMonitor* is in use so the ObjectMonitor should not be deflated; this is needed for operations on non-busy monitors so that ObjectMonitor values don't change while they are being queried. There is a new ObjectMonitorHandle helper to manage the ref_count.
• The ObjectMonitor::owner() accessor detects DEFLATER_MARKER and returns NULL in that case to minimize the places that need to understand the new DEFLATER_MARKER value.
• System.gc()/JVM_GC() causes a special monitor list cleanup request which uses the safepoint based monitor list mechanism. So even if AsyncDeflateIdleMonitors is enabled, the safepoint based mechanism is still used by this special case.
  • This is necessary for those tests that do something to cause an object's monitor to be inflated, clear the only reference to the object and then expect that enough System.gc() calls will eventually cause the object to be GC'ed even when the thread never inflates another object's monitor. Yes, we have several tests like that. :-)