Page History

...

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 count contentions a large negative value with cmpxchg() forces racing threads to retry. A racing thread would have set the owner field (after we stored DEFLATER_MARKER) and would be trying to increment the 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.

...

• 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()
  • most callers to enter() had to indirectly adapt to the protocol and retry their operations.
• Also these functions had to adapt and retry their operations:
  
  • ObjectSynchronizer::quick_enter()
  • ObjectSynchronizer::slow_enter()
  • ObjectSynchronizer::reenter()
  • ObjectSynchronizer::jni_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 and count contentions fields.
• 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. When the Async Monitor Deflation code sees an ObjectMonitor in the 'New' state, it is changed to the 'Old' state, but is not deflated. This prevents a newly allocated ObjectMonitor from being immediately deflated which could cause an inflation<->deflation oscillation.
• ObjectMonitor has a new ref_count field that is used 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. :-)