JDK-8218176 : [graal] gc tests fail with OutOfMemoryError
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 11,12,13
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2019-01-31
  • Updated: 2024-11-19
  • Resolved: 2024-11-19
Related Reports
Relates :  
Relates :  
Sub Tasks
JDK-8218202 :  
JDK-8255027 :  
Description
 stderr: [Exception in thread "HotSpotGraalManagement Bean Registration" 
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "HotSpotGraalManagement Bean Registration"
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
]
 exitValue = 1

java.lang.RuntimeException: Expected to get exit value of [0]

	at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:419)
	at gc.stress.TestStressG1Humongous.run(TestStressG1Humongous.java:77)
	at gc.stress.TestStressG1Humongous.main(TestStressG1Humongous.java:57)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:246)
	at java.base/java.lang.Thread.run(Thread.java:835)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]


test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]
Comments
This is an old test bug with no recent activity. I'm closing this as won't fix. Let's open a new Bug if a similar issue happens again.
19-11-2024

The test start failing again in JDK 15 because it was removed from ProblemList-graal.txt by JDK-8218173.
03-07-2020

It seems reasonable to treat the NoClassDefFoundError in String concat as a duplicate of JDK-8218173. However, there are other NoClassDefFoundError's in other system classes and OOM's in the main thread that look like test bugs.
13-02-2019

The exception in Graal/JVMCI doesn't seem to be the root cause. It appears that string concat became broken because of an OOM in a <clinit> (see JDK-8218173), and the test did not handle it gracefully: Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class java.lang.invoke.StringConcatFactory$MethodHandleInlineCopyStrategy at java.base/java.lang.invoke.StringConcatFactory.generate(StringConcatFactory.java:772) at java.base/java.lang.invoke.StringConcatFactory.doStringConcat(StringConcatFactory.java:681) at java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:597) at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:99) at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:307) at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:259) at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:249) at TestStressG1HumongousImpl.run(TestStressG1Humongous.java:111) at TestStressG1HumongousImpl.main(TestStressG1Humongous.java:94) startAllocationThreads(checkedAmountOfHObjects); countDownLatch.await(); GARBAGE.clear(); System.out.println("Allocated " + alocatedObjectsCount.get() + " objects."); Because of JDK-8218173, GARBAGE.clear() is not sufficient to allow the string concat to succeed.
09-02-2019

In general given a JIT is an optimisation mechanism, failure to be able to optimise is not a fatal error.
03-02-2019

It does seem related to JDK-8196611. Having Graal code running can cause unexpected allocations, JVMTI events, and exceptions. But should it cause the JVM to exit, or should it fail silently?
03-02-2019

isn't this bug just another manifestation of the known problem w/ the tests which provoke/expect OOME -- JDK-8196611?
01-02-2019

There have been sporadic failures of this test, (nearly?) all with Graal. This test is intentionally provoking frequent OOMEs. It launches several threads; each thread loops, allocating large objects and adding them to a per-thread collection. Once a test thread gets an OOME, it clears it's collection of large objects and ends. The failures seem to be arising because Graal is sometimes encountering an OOME too, and is insufficiently resilient to that.
01-02-2019