JDK-8251456 : [TESTBUG] compiler/vectorization/TestVectorsNotSavedAtSafepoint.java failed OutOfMemoryError
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2020-08-11
  • Updated: 2024-11-20
  • Resolved: 2020-08-13
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 13 JDK 15 JDK 16
11.0.10-oracleFixed 13.0.8Fixed 15.0.4Fixed 16 b12Fixed
Related Reports
Relates :  
JDK-8249608 - Vector register used by C2 compiled method corrupted at safepoint
Description
The following test failed due to OOM in the JDK16 CI:

compiler/vectorization/TestVectorsNotSavedAtSafepoint.java

Here's a snippet from the log file:

#section:main
----------messages:(4/374)----------
command: main -XX:-BackgroundCompilation -XX:+UseCountedLoopSafepoints -XX:LoopStripMiningIter=1000 TestVectorsNotSavedAtSafepoint test1
reason: User specified action: run main/othervm -XX:-BackgroundCompilation -XX:+UseCountedLoopSafepoints -XX:LoopStripMiningIter=1000 TestVectorsNotSavedAtSafepoint test1 
Mode: othervm [/othervm specified]
elapsed time (seconds): 3.571
----------configuration:(0/0)----------
----------System.out:(0/0)----------
----------System.err:(13/821)----------
java.lang.OutOfMemoryError: Java heap space
	at TestVectorsNotSavedAtSafepoint.main(TestVectorsNotSavedAtSafepoint.java:77)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:832)

JavaTest Message: Test threw exception: java.lang.OutOfMemoryError: Java heap space
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.OutOfMemoryError: Java heap space
----------rerun:(43/6085)*----------
Comments
Fix request (15u) - will label after testing completed. I'd like to backport this fix to jdk15u as a follow-up for JDK-8249608 as already mentioned above. The original patch applied cleanly. Slight changes is made to the test: added -XX:+IgnoreUnrecognizedVMOptions as suggested in JDK-8264179.
21-05-2021
Fix request (13u) - will label after testing completed. I'd like to backport this fix to jdk13u as a follow-up for JDK-8249608 as already mentioned above. The original patch applied cleanly. Slight changes is made to the test: added -XX:+IgnoreUnrecognizedVMOptions as suggested in JDK-8264179.
21-05-2021
Fix Request (11u) Follow-up for JDK-8249608 backport. Patch applies cleanly to 11u, passes the test.
08-09-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/f98751cd434e User: thartmann Date: 2020-08-13 14:00:14 +0000
13-08-2020
The test is supposed to fill up the heap to trigger GC which will then corrupt vector registers if they are not saved at safepoints. It sometimes fails with OOME because there is not enough heap space to allocate such large arrays. Adding a System.gc() call to the GarbageProducerThread triggers GCs more often without the need to allocate large garbage arrays and running for many (warmup) iterations. I've also strengthened verification of the array contents and used the exact same command line flags that Roland proposed in his fix for JDK-8193518: http://cr.openjdk.java.net/~thartmann/8251456/webrev.00/ I've verified that the test still reproduces JDK-8249608 and JDK-8193518. It's now much more reliable and reproduces the issues in every run.
12-08-2020
ILW = Test fails due to OOME (test bug), intermittent with single test, no workaround = MMH = P3
12-08-2020
Yes, the test fills up the heap to trigger GC work that will then corrupt some vector registers, I'll take a look.
12-08-2020
It seems test intentionally fills up Java heap. [~thartmann] or [~roland] please, look.
12-08-2020
It is new test added recently with JDK-8249608 fix. Test run with '-ea -esa -XX:CompileThreshold=100 -XX:-TieredCompilation' flags and test has ' -XX:-BackgroundCompilation -XX:+UseCountedLoopSafepoints -XX:LoopStripMiningIter=1000 '.
12-08-2020
Test machine has 4.00 GB memory and -XX:MaxRAMPercentage=12. I assume that test can use only 480Mb. Right?
12-08-2020