JDK-8202359 : [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-04-27
  • Updated: 2019-11-12
  • Resolved: 2018-10-03
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
11.0.6-oracleFixed 12 b15Fixed
Related Reports
Relates :  
Description
----------System.out:(10/478)*----------
CompileCommand: exclude compiler/uncommontrap/TestDeoptOOM.main
CompileCommand: exclude compiler/uncommontrap/TestDeoptOOM.m9_1
OOM caught in m1
OOM caught in m2_1
Timeout refired 1200 times
[1254.090s][error][attach] could not open pipe \\\\.\\pipe\\javatool-333402805 to send result of operation jcmd
[1254.611s][error][attach] could not open pipe \\\\.\\pipe\\javatool-125560333 to send result of operation jcmd
OOM caught in m3_3
OOM caught in m4
OOM caught in m5
----------System.err:(3/135)----------
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
Comments
Fix request (11u) Request backport for parity with Oracle 11.0.6. Patch applies cleanly, no regressions.
11-11-2019

Thank you, Doug We have other similar tests which fill up Java heap and have issue with Graal. I such cases we don't run them with Graal JIT. When we start testing libgraal we will review all such tests to make sure we run them with libgraal. For now we can simple exclude this test from running with Java Graal: * @summary failed reallocations of scalar replaced objects during deoptimization causes crash * + * @requires !vm.graal.enabled * @run main/othervm -XX:-BackgroundCompilation -Xmx128M -XX:+IgnoreUnrecognizedVMOptions -XX:+VerifyStack
03-10-2018

Another option is to restructure the test so that the method that must be compiled is parametrized by the amount of memory consumption it should perform. Then it can initially be run in a loop to trigger compilation and only on the second loop will it be called with a parameter value sufficient to cause OOME.
03-10-2018

This kind of test is always going to be a problem until we have libgraal. The test is intentionally consuming all available memory which means Graal will repeatedly fail with OOME during compilation. I would suggest modifying JVMCIRuntime::adjust_comp_level [1] to dial compilation back to C1 based on some heuristics such as whether the VM has ever thrown an OOME and how much current available memory there is. https://github.com/AdoptOpenJDK/openjdk-jdk/blob/63e954381d81e5c20a2507e9d34a067fbd0a2db0/src/hotspot/share/jvmci/jvmciCompiler.cpp#L198
03-10-2018

[~dnsimon] please, reassign this bug for investigation.
02-10-2018

Yes, happens for us with: CompileCommand: exclude compiler/uncommontrap/TestDeoptOOM.main CompileCommand: exclude compiler/uncommontrap/TestDeoptOOM.m9_1 Thread[JVMCI CompilerThread7,9,system]: Compilation of java.io.DataInputStream.readUTF(DataInput) failed: java.lang.OutOfMemoryError: Java heap space To disable compilation failure notifications, set CompilationFailureAction to Silent (e.g., -Dgraal.CompilationFailureAction=Silent). To print a message for a compilation failure without retrying the compilation, set CompilationFailureAction to Print (e.g., -Dgraal.CompilationFailureAction=Print). Retrying compilation of java.io.DataInputStream.readUTF(DataInput) Warning: adjusting CompilationFailureAction from Diagnose to Print after MaxCompilationProblemsPerAction (2) failed compilations Warning: adjusting CompilationFailureAction from Print to Silent after MaxCompilationProblemsPerAction (2) failed compilations [thread:12] scope: JVMCI CompilerThread7 [thread:12] scope: JVMCI CompilerThread7.Compiling.GraalCompiler Context: StructuredGraph:130{HotSpotMethod<DataInputStream.readUTF(DataInput)>} [thread:12] scope: JVMCI CompilerThread7.Compiling.GraalCompiler.FrontEnd.PhaseSuite Exception raised in scope JVMCI CompilerThread7.Compiling.GraalCompiler.FrontEnd.PhaseSuite: java.lang.OutOfMemoryError: Java heap space Context obj org.graalvm.compiler.phases.PhaseSuite@13779874 Context obj StructuredGraph:130{HotSpotMethod<DataInputStream.readUTF(DataInput)>} Context obj jdk.vm.ci.hotspot.HotSpotCodeCacheProvider@53f05f95 Context obj DebugDumpScope[2462] Thread[JVMCI CompilerThread3,9,system]: Compilation of java.io.ByteArrayInputStream.read() failed: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.OutOfMemoryError: Java heap space at parsing org.graalvm.compiler.hotspot.replacements.MonitorSnippets.tryEnterBiased(MonitorSnippets.java:326) at parsing org.graalvm.compiler.hotspot.replacements.MonitorSnippets.monitorenter(MonitorSnippets.java:244) at jdk.internal.vm.compiler@11-internal/org.graalvm.compiler.java.BytecodeParser.throwParserError(BytecodeParser.java:2400) at jdk.internal.vm.compiler@11-internal/org.graalvm.compiler.java.BytecodeParser.iterateBytecodesForBlock(BytecodeParser.java:3140) at jdk.internal.vm.compiler@11-internal/org.graalvm.compiler.java.BytecodeParser.processBlock(BytecodeParser.java:2944) at jdk.internal.vm.compiler@11-internal/org.graalvm.compiler.java.BytecodeParser.build(BytecodeParser.java:888) at jdk.internal.vm.compiler@11-internal/org.graalvm.compiler.java.BytecodeParser.parseAndInlineCallee(BytecodeParser.java:2419) at jdk.internal.vm.compiler@11-internal/org.graalvm.compiler.java.BytecodeParser.inline(BytecodeParser.java:2321) at jdk.internal.vm.compiler@11-internal/org.graalvm.compiler.java.BytecodeParser.tryInline(BytecodeParser.java:2195) at jdk.internal.vm.compiler@11-internal/org.graalvm.compiler.java.BytecodeParser.appendInvoke(BytecodeParser.java:1696) ...
04-09-2018

all of them also happened w/ graal as JIT.
25-06-2018

all the failures in comments are timeouts unless I'm missing something they aren't related to 'unexpected OOME'
25-06-2018

ILW = Test fails due to unexpected OOME (test bug), single test in hs-tier2 but very intermittent, no workaround = MMH = P3
02-05-2018

Possibly related but I suspect only in the sense that the OOME can hit at unexpected places and so cause the test to fail unexpectedly. I'll link the two bugs but unassign myself from this one. 8199882 is purely a VM robustness issue.
27-04-2018

[~dholmes] I see you are assignee for JDK-8199882, which is also related to the same test, so supposed you could take a look at this failure.
27-04-2018

~jjiang: Why was this assigned to me?
27-04-2018