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/89-for-jdk13jdk14.full/

Inc Webrev: http://cr.openjdk.java.net/~dcubed/8153224-webrev/89-for-jdk13jdk14.v2.06.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 JavaThreads and 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.

...

• New diagnostic option '-XX:AsyncDeflateIdleMonitors' that is default 'true' so that the new mechanism is used by default, but it can be disabled for potential failure diagnosis.
• ObjectMonitor deflation is still initiated or signaled as needed at a safepoint. When Async Monitor Deflation is in use, flags are set so that the work is done by JavaThreads and the ServiceThread which offloads the safepoint cleanup mechanism.
  ObjectSynchronizer::omAlloc() is modified to call (as needed) ObjectSynchronizer::deflate_per_thread_idle_monitors_using_JT(). Having the JavaThread cleanup its own per-thread monitor list permits this work to happen without any per-thread list locking or critical sections.
  • Having a JavaThread Having the ServiceThread deflate a potentially long list of in-use monitors could potentially delay the start of a safepoint. This is detected in ObjectSynchronizer::deflate_monitor_list_using_JT() which will save the current state when it is safe to do so and return to its caller to drop locks as needed before honoring the safepoint request.

• ObjectSynchronizer::inflate() has to be careful how omAlloc() is called. If the inflation cause is inflate_cause_vm_internal, then it is not safe to deflate monitors on the per-thread lists so we skip that. When monitor deflation is done, inflate() has to do the oop refresh dance that is common to any code that can go to a safepoint while holding a naked oop. And, no you can't use a Handle here either. :-)
• Everything else is just monitor list management, infrastructure, logging, debugging and the like. :-)

...

• Changes to the ServiceThread mechanism by the Async Monitor Deflation project (when async deflation is enabled):

  • The ServiceThread will wake up every GuaranteedSafepointInterval to check for cleanup tasks.

    • This allows is_async_deflation_needed() to be checked at the same interval.

  • The ServiceThread handles deflating global idle monitors and sets deflating the omShouldDeflateIdleMonitors request flag for the per-thread idle monitor checkmonitors.

• 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.

...