JDK-8269849 : vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: test
  • Affected Version: 17,18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2021-07-04
  • Updated: 2022-01-13
  • Resolved: 2021-07-21
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 17 JDK 18
17.0.3-oracleFixed 18 b07Fixed
Related Reports
Relates :  
JDK-8260684 - vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed out
Relates :  
JDK-8227309 - Handle OOM when rematerializing objects less surprising
Description
The following test failed in the JDK17 CI:

vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java

Here's a snippet from the log file:

Failures summary:
java.lang.OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects
----------System.err:(16/969)----------
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.PhantomReference.phantom001.phantom001.main(phantom001.java:93)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:833)

JavaTest Message: Test threw exception: nsk.share.TestFailure: Test exit code: 97
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: nsk.share.TestFailure: Test exit code: 97
----------rerun:(36/7636)*----------

The test task's JVM args are:

-XX:+CreateCoredumpOnCrash -XX:+UseZGC
Comments
Fix request [17u] I backport this for parity with 17.0.3-oracle. No risk, only a test change. Clean backport. Test passes. SAP nightly testing passes.
13-01-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/85 Date: 2022-01-12 13:31:40 +0000
12-01-2022
Changeset: b7245c61 Author: Leonid Mesnik <lmesnik@openjdk.org> Date: 2021-07-21 18:07:43 +0000 URL: https://git.openjdk.java.net/jdk/commit/b7245c6164df3f01c34f4f3c94185a6b6d338551
21-07-2021
The description of JDK-8226536 sounds like a general problem, but the associated fix was just for a specific occurrence that was happening in the test framework. This failure seems to be a different specific occurrence. It seems like a more general fix for OOME in deopt would be desirable (assuming that's possible), which is what JDK-8227309 seems to be. But even if we had that, the test framework could still OOME in unexpected places because of an allocation in an unprotected context while other threads are eating memory.
07-07-2021
I think the problem with the VM unexpectedly exiting is is a known issue with C2: see JDK-8227309 . JDK-8226536 referenced there contains some more thoughts on this.
05-07-2021
The kind of OOME thrown is from Deoptimization::realloc_objects. I think this is a bug in the test framework, and not a GC bug. phantom001.The tests run() calls eatMemory, but also catches and discards OOME. But there are multiple threads running that. And the framework that does that doesn't seem to protect against OOME. If the executing threads have brought things close to OOME when one of the invocations of phantom001.Test.run returns, and that return hits deopt for some reason (or does any other allocation), it could push things over the edge and trigger OOME in an unprotected context.
04-07-2021
[~kbarrett] - Let's ask [~lmesnik] where this bug should go... I suspect that it might stay in hotspot/gc since the OOME throwing infrastructure is primarily used by GC tests, but I also wouldn't be surprised to see it move to hotspot/test.
04-07-2021
This included the JDK-8260684 test timeout fix.
04-07-2021