-
Enhancement
-
Resolution: Fixed
-
P4
-
12
-
b24
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8216253 | 13 | Aleksey Shipilev | P4 | Resolved | Fixed | team |
JDK-8224195 | 11.0.4 | Aleksey Shipilev | P4 | Resolved | Fixed | b04 |
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
- backported by
-
JDK-8216253 Introduce diagnostic flag to abort VM on too long VM operations
- Resolved
-
JDK-8224195 Introduce diagnostic flag to abort VM on too long VM operations
- Resolved
- relates to
-
JDK-8215374 32-bit build failures after JDK-8181143 (Introduce diagnostic flag to abort VM on too long VM operations)
- Resolved
-
JDK-8269523 runtime/Safepoint/TestAbortOnVMOperationTimeout.java failed when expecting 'VM operation took too long'
- Resolved
-
JDK-8227528 TestAbortVMOnSafepointTimeout.java failed due to "RuntimeException: 'Safepoint sync time longer than' missing from stdout/stderr"
- Closed
-
JDK-8213992 Rename and make DieOnSafepointTimeout the diagnostic option
- Resolved