JDK-8213992 : Rename and make DieOnSafepointTimeout the diagnostic option
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-11-16
  • Updated: 2019-08-15
  • Resolved: 2018-11-20
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 Other
11.0.3Fixed 12 b21Fixed openjdk8u212Fixed
Related Reports
Relates :  
Relates :  
Description
Current option is defined as:

  develop(bool, DieOnSafepointTimeout, false,                               
          "Die upon failure to reach safepoint (see SafepointTimeout)") 

While the original option was conceived to aid debugging during the VM development, it is also useful in product builds to terminate VM when it is stuck.

We can make this option diagnostic, and also rename it to match other AbortVMOn* options.

For example (builds and passes tier1):
 http://cr.openjdk.java.net/~shade/8213992/8213992.patch

Comments
Fix Request I would like to backport this fix to jdk11u, it helps to debug long safepoint sync time on production system. The jdk12 patch applies cleanly to jdk11u.
23-11-2018

RFR: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-November/035255.html
16-11-2018

What I don't like about "product" option is that the suggestion it is fully supported. (Which also gets interesting when product option crashes VM hard). "diagnostic" keeps the failure mode available in product builds without attached notions of support. Users that want fail-fast can then use that option on "we know what we are doing" basis, which is better than nothing.
16-11-2018

I think jury is still out on whether stuck VM should remain stuck (to aid debugging), or it should instead fail fast (to let failover handle it). "diagnostic" largely follows what JDK-8181143 and JDK-8212070 are doing. It my mind, these are diagnostic in the sense you would not use them with VM that behaves normally, and only enable when you suspect a VM bug that needs to be nailed down, hopefully with hs_err. But if we interpret it like you do, then SafepointTimeout itself should be diagnostic, not product?
16-11-2018

I would have thought that a "stuck VM" in product mode was better left alive so it could be interrogated/inspected some way to determine why it has become stuck. I don't see how this suits diagnostic mode. A diagnostic flag is something you suggest to try and diagnose a recurring problem. This won't diagnose anything. Sounds to me like you actually want this to be a product flag.
16-11-2018