Page History

...

   ((om_list_globals.population - om_list_globals.free_count) / om_list_globals.population) > NN%

• If MonitorBound is exceeded (default is 0 which means off), cleanup safepoint will be induced.
• For this option, exceeded means:

(om_list_globals.population - om_list_globals.free_count) > MonitorBound

• This is a very difficult option to use correctly as it does not scale.
• The MonitorBound option has been deprecated via JDK-8230938.

• Changes to the safepoint deflation mechanism by the Async Monitor Deflation project (when async deflation is enabled):
  • If System.gc() is called, then a special deflation request is made which invokes the safepoint deflation mechanism.
  • Added the AsyncDeflationInterval diagnostic option (default 250 millis, 0 means off) to prevent MonitorUsedDeflationThreshold requests from swamping the ServiceThread.
    • Description: Async deflate idle monitors every so many milliseconds when MonitorUsedDeflationThreshold is exceeded (0 is off).
    • A special deflation request can cause an async deflation to happen sooner than AsyncDeflationInterval.
  • SafepointSynchronize::is_cleanup_needed() now calls:
    • ObjectSynchronizer::is_safepoint_deflation_needed() instead of ObjectSynchronizer::is_cleanup_needed().
    • is_safepoint_deflation_needed() returns true only if a special deflation request is made (see above).
  • SafepointSynchronize::do_cleanup_tasks() now (indirectly) calls:
    • ObjectSynchronizer::do_safepoint_work() instead of ObjectSynchronizer::deflate_idle_monitors().
    • do_cleanup_tasks() can be called for non deflation related cleanup reasons and that will still result in a call to do_safepoint_work().
  • ObjectSynchronizer::do_safepoint_work() only does the safepoint cleanup tasks if there is a special deflation request. Otherwise it just sets the is_async_deflation_requested flag and notifies the ServiceThread.
  • ObjectSynchronizer::deflate_idle_monitors() and ObjectSynchronizer::deflate_thread_local_monitors() do nothing unless there is a special deflation request.

...

• Other invocation changes by the Async Monitor Deflation project (when async deflation is enabled):

  • VM_Exit::doit_prologue() will request a special cleanup to reduce the noise in 'monitorinflation' logging at VM exit time.

  • Before the final safepoint in a non-System.exit() end to the VM, we will request a special cleanup to reduce the noise in 'monitorinflation' logging at VM exit time.

  • The following whitebox test functions will request a special cleanup:

    • WB_G1StartMarkCycle()

    • WB_FullGC()
    • WB_ForceSafepoint()

Gory Details

• 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()
  • 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::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.
• 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. :-)