JDK-8284234 : Tests provoking OOME failing with OOME in thread "Reference Handler"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 19,20,21,24,repo-loom
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-04-03
  • Updated: 2024-11-06
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 24
24Unresolved
Related Reports
Duplicate :  
JDK-8285509 - loom: vmTestbase/gc/gctests/SoftReference/soft001/soft001.java fails with "Exception in thread "Reference Handler" java.lang.OutOfMemoryError: Java heap space"
Duplicate :  
JDK-8286420 - gc/gctests/PhantomReference/phantom001/phantom001.java failed with "Exception in thread "Reference Handler" java.lang.OutOfMemoryError: Java heap space"
Duplicate :  
JDK-8285961 - vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java failed with OutOfMemoryError
Relates :  
JDK-8282492 - vmTestbase/gc/** timeout when run with wrapper in loom repo
Relates :  
JDK-8287887 - Change vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java to not run with -Xcomp
Relates :  
JDK-8278569 - vmTestbase/nsk/stress/jni/gclocker/gcl001.java times out in loom
Relates :  
JDK-8254852 - gc locker related tests time out
Sub Tasks
JDK-8285773 :  
Replace Algorithms.eatMemory(...) with WB.fullGC() in vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java - Resolved
JDK-8285951 :  
Replace Algorithms.eatMemory(...) with WB.fullGC() in vmTestbase_vm_gc_ref tests - Resolved
Description
Test
vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
fails with 
Exception in 
gc.gctests.ReferencesGC.ReferencesGC$Worker@5bf941
nsk.share.TestFailure: Expected 540 references enqueued: 0
	at gc.gctests.ReferencesGC.ReferencesGC$Worker.run(ReferencesGC.java:194)
	at nsk.share.runner.ThreadsRunner$ManagedThread.run(ThreadsRunner.java:128)
	at java.base/java.lang.Thread.run(Thread.java:1532)
Failures summary:
nsk.share.TestFailure: Expected 540 references enqueued: 0
	at gc.gctests.ReferencesGC.ReferencesGC$Worker.run(ReferencesGC.java:194)
	at nsk.share.runner.ThreadsRunner$ManagedThread.run(ThreadsRunner.java:128)
	at java.base/java.lang.Thread.run(Thread.java:1532)
----------System.err:(15/856)----------
Exception in thread "Reference Handler" java.lang.OutOfMemoryError: Java heap space
nsk.share.TestFailure: Test exit code: 97
	at nsk.share.test.Tests$TestRunner.execute(Tests.java:90)
	at nsk.share.test.Tests$TestRunner.run(Tests.java:96)
	at nsk.share.gc.GC.runTest(GC.java:114)
	at gc.gctests.ReferencesGC.ReferencesGC.main(ReferencesGC.java:61)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:1532)
Comments
Hello David, > Recent failures are due to: > Error. unexpected exit code: 1, doesn't match exit status: "Passed." which was reported by the test process > This is different to the original reported error. The recent version of jtreg (which is in use here) introduced a fix where it now correctly reports any failure that happens after the test's code execution has completed but before the JVM has actually shutdown. Previously, such failures went unnoticed because the test was marked as passed. The error message above suggests that after the test's code completed executing successfully but before the JVM completed its shutdown, there appears to have been a OOM.
20-10-2024
Recent failures are due to: Error. unexpected exit code: 1, doesn't match exit status: "Passed." which was reported by the test process This is different to the original reported error.
14-10-2024
Here's a log file snippet from the jdk-24+18-2022-tier8 sighting: vmTestbase/gc/gctests/FinalizeTest04/FinalizeTest04.java #section:main ----------messages:(6/342)---------- command: main -XX:-UseGCOverheadLimit gc.gctests.FinalizeTest04.FinalizeTest04 reason: User specified action: run main/othervm -XX:-UseGCOverheadLimit gc.gctests.FinalizeTest04.FinalizeTest04 started: Fri Oct 04 01:16:10 UTC 2024 Mode: othervm [/othervm specified] finished: Fri Oct 04 01:16:54 UTC 2024 elapsed time (seconds): 44.694 ----------configuration:(0/0)---------- ----------System.out:(11/252)---------- Stress time: 30 seconds Stress iterations factor: 1 Stress threads factor: 1 Stress runs factor: 1 Max memory: 1073741824 Sleep time: 500 Iterations: 0 Number of threads: 24 Run GC thread: false Run mem diag thread: false Run forever: false ----------System.err:(1/72)---------- Exception in thread "main" java.lang.OutOfMemoryError: Java heap space ----------rerun:(42/7070)*---------- <snip> result: Failed. Unexpected exit from test [exit code: 1]
04-10-2024
Also: vmTestbase/gc/gctests/FinalizeTest04/FinalizeTest04.java🎲 Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
13-05-2022
Also we can see other failure modes depending on where exactly the OOME hits. Loom changed a lot of code to use ReentrantLock and Condition instead of synchronized and wait/notify. But ReentrantLock is not hardened sufficiently against OOME and that can lead to mysterious IllegalMonitorStateException when doing an unlock in a finally block that was wrapping an await() call that threw OOME trying to reacquire the lock after the wait. e.g. java.lang.IllegalMonitorStateException at java.base/java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:175) at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1007) at java.base/java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:494) at java.base/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:236) at gc.gctests.SoftReference.soft001.soft001$Test.run(soft001.java:173)
13-05-2022
This is happening in mainline CI now.
12-05-2022
This might be why the gcLocker tests time out. We get an OOM in the (at least one) JDK-8282492 tests, ie: Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "VirtualThread-unparker"
04-05-2022
The reference tests provoke OOME only to force reference clearing. The possible fix is to force it directly with WB.fullGC(). Another possible fix would be to throw SkippedException in DefaultUncaughtExceptionHandler. However, it might also cause OOME and still fail. We might also want to verify that a last-ditch GC or something similar is called for each GC.
28-04-2022
While running vm.gc tests with virtual threads it might also hit Exception in thread "VirtualThread-unparker" java.lang.OutOfMemoryError: Java heap space So any OOME might cause problems when virtual threads are used.
27-04-2022
The test vmTestbase/gc/gctests/SoftReference/soft002/TestDescription.java like any OOME provoking test might hit OOME in wrong thread.
13-04-2022
It might be a test problem rather than a loom issue. OOME might happen in any thread, probably it is needed to rewrite test provoking GC using WB
03-04-2022