JDK-8212070 : Introduce diagnostic flag to abort VM on failed JIT compilation
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,11,12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-10-11
  • Updated: 2024-08-01
  • Resolved: 2018-11-19
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 openjdk8u282Fixed
Related Reports
Relates :  
JDK-8213992 - Rename and make DieOnSafepointTimeout the diagnostic option
Description
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-October/030915.html

Aleksey:
I want to run our performance tests with usual compiler configuration, and make VM fail if/when we fail to compile the method for some reason -- probably due to VM bugs -- instead of silently regressing performance, and leaving me scratching my head what had happened. This might be of interest for high-performance users too, if they want to treat current  graceful degradation as error condition instead.

This is similar to CompileTheWorld, except it does normal compilation with usual profiling and optimization, basically running in the mode we would expect production to run.

Vladimir:
Okay, in such case I would suggest to make general (not Shenandoah specific) diagnostic flag similar to AbortVMOnException flag. Something like AbortVMOnCompileFailure. And code should by in CompileBroker::post_compile(). 

EDIT: The final option name is -XX:+AbortVMOnCompilationFailure.
Comments
Nice that the lack of JDK-8136421's refactoring actually makes this easier. I presume the same was the case for backporting JFR (JDK-8199712)
22-10-2020
Fix Request (8u) Same reason as for 11u. Patch is even simpler for 8u (acked by stuefe and phh): https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-October/012792.html. Passes tier1 with the patch, and shows up new interesting failures with flag enabled.
14-10-2020
Fix Request This diagnostic option is useful to diagnose compiler-failure types of performance troubles. The option is diagnostic, so risk is low. It would be good to have it in 11, where most users would end up to be.
28-11-2018
URL: http://hg.openjdk.java.net/jdk/jdk/rev/b8c88c64abf0 User: shade Date: 2018-11-19 11:18:51 +0000
19-11-2018
Webrev: http://cr.openjdk.java.net/~shade/8212070/webrev.01/ Ran tier1 for fun, these are the tests that would fail if we turn the option on. It seems -Xcomp makes ~40 tests blow the code cache on tier3. Also, there are some "Never compilable: out of nodes parsing method" for the tests that are supposed to compile fine? $ CONF=linux-x86_64-server-fastdebug make images run-test TEST=jtreg:test/hotspot/jtreg:tier1 TEST_VM_OPTS="-XX:+UnlockDiagnosticVMOptions -XX:+AbortVMOnCompileFailure" # fatal: Not compilable on level 1: CodeBuffer overflow compiler/c1/TestLinearScanOrderMain.java: # fatal: Not compilable on level 3: CodeBuffer overflow compiler/arraycopy/TestReduceBulkZeroingDisabled.java compiler/c1/Test6756768.java compiler/c1/Test6756768_2.java compiler/c1/Test6757316.java compiler/c1/Test7042153.java compiler/c1/Test7123108.java compiler/c1/Test8004051.java compiler/c2/Test6877254.java compiler/c2/Test7125879.java compiler/c2/cr6663854/Test6663854.java compiler/c2/cr6711117/Test.java compiler/c2/cr6712835/Test6712835.java compiler/c2/cr6714694/Tester.java compiler/codegen/Test6875866.java compiler/codegen/Test6935535.java compiler/codegen/Test8005033.java compiler/cpuflags/TestSSE4Disabled.java compiler/escapeAnalysis/Test6895383.java compiler/escapeAnalysis/Test6896727.java compiler/escapeAnalysis/cr6716441/Tester.java compiler/floatingpoint/TestFloatJNIArgs.java compiler/interpreter/cr7116216/StackOverflow.java compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java compiler/loopopts/TestSplitIfBlocksDisabled.java compiler/memoryinitialization/ZeroTLABTest.java compiler/runtime/Test6859338.java compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.java compiler/runtime/criticalnatives/lookup/LookUp.java gc/epsilon/CriticalNativeArgs.java gc/epsilon/CriticalNativeStress.java gc/epsilon/TestByteArrays.java gc/epsilon/TestManyThreads.java gc/epsilon/TestObjects.java gc/epsilon/TestRefArrays.java gc/g1/TestJNIWeakG1/TestJNIWeakG1.java runtime/CreateMirror/ArraysNewInstanceBug.java runtime/Nestmates/membership/TestNestmateMembership.java runtime/Nestmates/privateConstructors/TestInvokeSpecial.java runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ArrayIndexOutOfBoundsExceptionTest.java runtime/jni/ReturnJNIWeak/ReturnJNIWeak.java # fatal: Not compilable on level 3: osr entry must have been visited for osr compile compiler/c1/Test8172751.java # fatal: Never compilable: out of nodes parsing method compiler/c2/Test8062950.java compiler/c2/TestSignedByteCompare.java compiler/c2/TestUnsignedByteCompare.java # fatal: Not compilable on level 4: exception throw compiler/jvmci/compilerToVM/IsCompilableTest.java compiler/jvmci/events/JvmciNotifyInstallEventTest.java # fatal: Not compilable on level 4: no compiler configured compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java # fatal: Never compilable: infinite loop compiler/loopopts/StoreMovedBeforeInfiniteLoop.java # fatal: Never compilable: out of nodes before macro expansion compiler/loopopts/TestOverunrolling.java: Tests correct dominator information after over-unrolling a loop.
15-11-2018
Yes, it could be done. But the issue here is we don't know which method compilation will fail. We can introduce an other flag similar to AbortVMOnExceptionMessage where a message could be specified on which to abort.
11-10-2018
to make it more useful, I think it makes sense to have AbortVMOnCompileFailure settable via compiler control directives. in that case, users will be able to choose what failed compilations should be treated as errors.
11-10-2018