JDK-8273095 : vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java fails with "wrong OOME"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-08-27
  • Updated: 2022-04-27
  • Resolved: 2021-11-22
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.4-oracleFixed 18 b26Fixed
Related Reports
Relates :  
JDK-8226536 - Catch OOM from deopt that fails rematerializing objects
Relates :  
JDK-8227309 - Handle OOM when rematerializing objects less surprising
Sub Tasks
JDK-8273462 :  
ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode - Resolved
Description
### TRACE 1: Test started.
### TRACE 1: RNG seed = 2617869316039064307 (0x24548a45dae73af3)
For random generator using seed: 2617869316039064307
To re-run test with same seed value please add "-Djdk.test.lib.random.seed=2617869316039064307" to command line.
### TRACE 1: Caught OOME : Java heap space: failed reallocation of scalar replaced objects
#>  
#>  WARNING: switching log to verbose mode,
#>      because error is complained
#>  
# ERROR: Test caught an exception: 
# ERROR: java.lang.RuntimeException: TEST FAIL : wrong OOME
# ERROR: 	at vm.mlvm.anonloader.stress.oome.heap.Test.checkOOME(Test.java:67)
# ERROR: 	at vm.mlvm.share.MlvmOOMTest.run(MlvmOOMTest.java:53)
# ERROR: 	at vm.mlvm.share.MlvmTestExecutor.runMlvmTestInstance(MlvmTestExecutor.java:382)
# ERROR: 	at vm.mlvm.share.MlvmTestExecutor.runMlvmTest(MlvmTestExecutor.java:327)
# ERROR: 	at vm.mlvm.share.MlvmTestExecutor.launch(MlvmTestExecutor.java:244)
# ERROR: 	at vm.mlvm.share.MlvmTestExecutor.launch(MlvmTestExecutor.java:186)
# ERROR: 	at vm.mlvm.share.MlvmTestExecutor.launch(MlvmTestExecutor.java:157)
# ERROR: 	at vm.mlvm.share.MlvmTestExecutor.launch(MlvmTestExecutor.java:133)
# ERROR: 	at vm.mlvm.anonloader.stress.oome.heap.Test.main(Test.java:91)
# ERROR: 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
# ERROR: 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
# ERROR: 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
# ERROR: 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
# ERROR: 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
# ERROR: 	at java.base/java.lang.Thread.run(Thread.java:833)
# ERROR: Caused by: java.lang.OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects
Comments
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/360 Date: 2022-04-25 14:47:45 +0000
25-04-2022
Fix Request (17u): Should get backported for parity with 17.0.4-oracle. Applies cleanly except removal from problem list because it's not problem listed in 17u. Test has passed.
25-04-2022
Changeset: f62b81c3 Author: Dean Long <dlong@openjdk.org> Date: 2021-11-22 23:17:46 +0000 URL: https://git.openjdk.java.net/jdk/commit/f62b81c3b5e34895e06bedec137bcef701d49df6
22-11-2021
I can reproduce this with jdk-18+14, but not with the latest JDK. I'm guessing this has to do with recent changes to inlining heuristics. Also, it seems to be a different problem than JDK-8226536. Calling eatMemory through a MethodHandle (as in 8226536) doesn't help. I see no evidence that the OOME is not being caught. Rather, it is being caught correctly, but the test expects only "Java heap space" as the exception message, and rejects the more specific "Java heap space: failed reallocation of scalar replaced objects" message. Possible solutions I can think of: 1) relax the message check (use startsWith instead of equals) 2) run the test with -XX:-EliminateAllocations to turn off the c2 optimization that triggers the different OOME message. This is consistent with how we already run the test with -XX:-UseGCOverheadLimit to disable yet another OOME message that the test doesn't like.
20-11-2021
ILW = MMH = P3
31-08-2021
I filed this as hotspot/runtime because it seems like the test should not be assuming that, after eating all memory, the OOME thrown is from a predictable place.
27-08-2021