Bug ID: JDK-8181143 Introduce diagnostic flag to abort VM on too long VM operations

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 11	JDK 12	JDK 13
11.0.4Fixed	12 b24Fixed	13Fixed

We now have SafepointTimeout machinery, that covers the "synchronization" part of the safepoint, i.e. the phase where threads are coming to a safepoint. But some use cases would enjoy the JVM mode where it exits if the _entire_ synchronized-at-safepoint, including the execution of associated VM operations, was handled by timeout machinery. 

Since VMThread is blocked executing the actual VM operation, it makes sense to use the existing periodic tasks / WatcherThread machinery to sample for safepoint, and act accordingly. It seems that if we are timeout-ing in the middle of VM operation, no recovery action is possible, and the only option is to crash JVM hard, hoping the deployment handles this properly.

Example patch:
  http://cr.openjdk.java.net/~shade/8181143/webrev.01/

Example output:
  http://cr.openjdk.java.net/~shade/8181143/LongAlloc.java
  http://cr.openjdk.java.net/~shade/8181143/g1.txt

Fix Request This is a helpful feature to diagnose too long running VM operations. I think it would be beneficial to have in the LTS release (jdk11u-dev), too. Risk is low because the feature is not active by default. Applies almost cleanly (only needs manual resolution because neighboring hunk has changed: include in vmThread.hpp). Needs to be backported together with JDK-8215374 which fixes a minor bug in the original change. Reviewed in thread https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-May/034202.html and tested in jdk11u-dev.
09-05-2019
The included test provides a nice example how to use this diagostic feature: -XX:+UnlockDiagnosticVMOptions -XX:+AbortVMOnVMOperationTimeout -XX:AbortVMOnVMOperationTimeoutDelay=... When you get an hs_err file, you should find an "Event: ... Executing VM operation: GenCollectForAllocation" showing the name of the long running VM operation.
08-05-2019
RFR: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-November/035256.html
16-11-2018
Even better symmetry with SafepointTimeout: http://cr.openjdk.java.net/~shade/8181143/webrev.03/
16-11-2018
Rebased for jdk/jdk and cleaned up a bit: http://cr.openjdk.java.net/~shade/8181143/webrev.02/ (still drafty)
16-11-2018

Relates :	JDK-8215374 - 32-bit build failures after JDK-8181143 (Introduce diagnostic flag to abort VM on too long VM operations)
Relates :	JDK-8213992 - Rename and make DieOnSafepointTimeout the diagnostic option
Relates :	JDK-8227528 - TestAbortVMOnSafepointTimeout.java failed due to "RuntimeException: 'Safepoint sync time longer than' missing from stdout/stderr"
Relates :	JDK-8269523 - runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long'