Page History

*** THIS WIKI IS BEING UPDATED FOR THE v2.11 VERSION. ***

Table of Contents:

...

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

Full Webrev: 1314-for-jdk15+1121.v2.1011.full

Inc Webrev: 1314-for-jdk15+1121.v2.1011.inc

Background

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

...

1. Setting a NULL owner field to DEFLATER_MARKER with cmpxchg() forces any contending thread through the slow path. A racing thread would be trying to set the owner field.
2. Making a zero ref_count contentions field a large negative value with cmpxchg() forces racing threads to retry. A racing thread would would be trying to increment the ref_count contentions field.
3. If the owner field is still equal to DEFLATER_MARKER, then we have won all the races and can deflate the monitor.

...

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 places (deflation and saving an ObjectMonitor* in an ObjectMonitorHandleObjectMonitor::enter()). Only one of the possible racing scenarios can win and the losing scenarios all adapt to the winning scenario's object header value.

3) Using "owner" or "

...

contentions" With Interference Detection

Various code paths have been updated to recognize an owner field equal to DEFLATER_MARKER or a negative ref_count contentions field and those code paths will retry their operation. This is the shortest "Key Part" description, but don't be fooled. See "Gory Details" below.

An Example of ObjectMonitor Interference Detection

*** THIS SUBSECTION NEEDS SUBSTANTIAL REWORK WITH v2.11 ***

ObjectMonitor::save_om_ptr() is used to safely save an ObjectMonitor* in an ObjectMonitorHandle. ObjectSynchronizer::deflate_monitor_using_JT() is used to asynchronously deflate an idle monitor. save_om_ptr() and deflate_monitor_using_JT() can interfere with each other. The thread calling save_om_ptr() (T-save) is potentially racing with another JavaThread (T-deflate) so both threads have to check the results of the races.

...

ObjectMonitor::install_displaced_markword_in_object() is called from two places so we can have a race between a T-save enter thread and a T-deflate thread:

Start of the Race

    T-save                                   enter                                          object           T-deflate
    -----------------------------------------------  +-------------+  -----------------------------------------------
    install_displaced_markword_in_object(oop obj) {  | mark=om_ptr |  install_displaced_markword_in_object(oop obj) {
      dmw = header()                                 +-------------+    dmw = header()
      obj->cas_set_mark(dmw, this)                                      obj->cas_set_mark(dmw, this)                                                              }

• • The data field (mark) is at its starting value.
  • 'dmw' is a local copy in each thread.
  • T-save enter and T-deflate are both calling install_displaced_markword_in_object() at the same time.
  • Both threads are poised to call cas_set_mark() at the same time.

Either Thread Wins the Race

    T-saveenter                                                                             object            T-deflate
    -----------------------------------------------  +-------------+   -----------------------------------------------
    install_displaced_markword_in_object(oop obj) {  | mark=dmw    |   install_displaced_markword_in_object(oop obj) {
      dmw = header()                                 +-------------+     dmw = header()
      obj->cas_set_mark(dmw, this)                                       obj->cas_set_mark(dmw, this)

• • It does not matter whether T-save enter or T-deflate won the cas_set_mark() call; in this scenario both were trying to restore the same value.
  • The object's mark field has changed from 'om_ptr' → 'dmw'.

...

Hashcodes and Object Header Interference

*** THIS SUBSECTION NEEDS SUBSTANTIAL REWORK WITH v2.11 ***

If we have a race between a T-deflate thread and a thread trying to get/set a hashcode (T-hash), then the race is between the ObjectMonitorHandle.save_om_ptr(obj, mark) call in T-hash and deflation protocol in T-deflate.

...

ObjectSynchronizer::deflate_monitor_list_using_JT(ObjectMonitor* volatile * list_p, int volatile * count_p, ObjectMonitor** free_head_p, ObjectMonitor** free_tail_p, ObjectMonitor** saved_mid_p)

*** THIS SUBSECTION NEEDS SUBSTANTIAL REWORK WITH v2.11 ***

ObjectSynchronizer::deflate_monitor_list_using_JT() is responsible for asynchronously deflating idle ObjectMonitors using a JavaThread. This function uses the more complicated lock-cur_mid_in_use-and-mid-as-we-go protocol because om_release() can do list deletions in parallel. We also lock-next-next-as-we-go to prevent an om_flush() that is behind this thread from passing us. Because this function can asynchronously interact with so many other functions, this is the largest clip of code:

...

• Counterpart function mapping for those that know the existing code:
  • ObjectSynchronizer class:
    • deflate_idle_monitors() has deflate_idle_monitors_using_JT(), 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:
    
    • 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::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. :-)