JDK-8058176 : [mlvm] tests should not allow code cache exhaustion
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,9,11,14,15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-09-10
  • Updated: 2024-01-03
  • Resolved: 2021-04-14
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 17 JDK 8
11.0.23-oracleFixed 17 b19Fixed 8u411Fixed
Related Reports
Duplicate :  
JDK-8079646 - [mlvm] Avoid CodeCache overflows in general MLVM tests
Duplicate :  
JDK-8208255 - [mlvm] vm/mlvm/meth/stress/compiler/sequence fails with OOM
Duplicate :  
JDK-8208235 - mlvm/meth/stress/jni/nativeAndMH/Test.java timed out
Duplicate :  
JDK-8193082 - vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/Test.java failed in PIT w/ ERROR at nativeAndMH.c:51
Relates :  
JDK-8257761 - [mlvm] make JDI tests tolerate exceptions caused by code cache exhaustion
Relates :  
JDK-8265349 - vmTestbase/../stress/compiler/deoptimize/Test.java fails with OOME due to CodeCache exhaustion.
Relates :  
JDK-8079646 - [mlvm] Avoid CodeCache overflows in general MLVM tests
Relates :  
JDK-8263398 - Adjust mlvm stress tests code cache size monitoring if 8263377 is implemented.
Relates :  
JDK-8058092 - Test vm/mlvm/meth/stress/compiler/deoptimize. Assert in src/share/vm/classfile/systemDictionary.cpp: MH intrinsic invariant
Relates :  
JDK-8233491 - Crash in AdapterHandlerLibrary::get_adapter with CDS due to code cache exhaustion
Relates :  
JDK-8269613 - vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java fails with OOME in CodeCache
Sub Tasks
JDK-8240135 :  
ProblemList vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 - Resolved
Description
Hotspot can throw java.lang.VirtualMachineError or java.lang.InternalError around calls if there is no code cache space left. This becomes most problematic with tests that stress method handles and produce a lot of different signatures for which the JVM has to create lot of c2i i2c adapters and in case of MH intrinsics - interpreter and compiled versions of intrinsics. The tests need to be hardened to tolerate such failures.

How to reproduce: run any mlvm test (in my case it was vm/mlvm/meth/stress/compiler/deoptimize) with restricted code cache -XX:ReservedCodeCacheSize=8M
Comments
Fix request [11u] I backport this for parity with 11.0.23-oracle. No risk, only tests change. ProblemList change. Test passes. SAP nightly testing passed.
01-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2419 Date: 2023-12-27 03:16:56 +0000
27-12-2023
Changeset: 4c83d24f Author: Evgeny Nikitin <enikitin@openjdk.org> Committer: Igor Ignatyev <iignatyev@openjdk.org> Date: 2021-04-14 17:32:53 +0000 URL: https://git.openjdk.java.net/jdk/commit/4c83d24f
14-04-2021
Raised a separate bug for the JDI part: JDK-8257761
04-12-2020
I confirm, the problem still persists. Forgot to un-problemlist the problematic test cases.
14-09-2020
[~enikitin], if we believe that the problem magically disappeared, the problem listed tests[1] should be returned back to execution (modulo breakpointOtherStratum which is problem-listed due to this as well as still open JDK-8208257) [1] ag 8058176 test/hotspot/jtreg/ProblemList* test/hotspot/jtreg/ProblemList.txt 147:vmTestbase/vm/mlvm/meth/func/java/throwException/Test.java 8058176 generic-all 148:vmTestbase/vm/mlvm/meth/func/jdi/breakpointOtherStratum/Test.java 8208257,8058176 generic-all 149:vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 8058176 generic-all 150:vmTestbase/vm/mlvm/meth/stress/compiler/i2c_c2i/Test.java 8058176 generic-all 151:vmTestbase/vm/mlvm/meth/stress/compiler/sequences/Test.java 8058176 generic-all 152:vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java 8058176 generic-all 153:vmTestbase/vm/mlvm/meth/stress/java/sequences/Test.java 8058176 generic-all 154:vmTestbase/vm/mlvm/meth/stress/jdi/breakpointInCompiledCode/Test.java 8058176 generic-all
12-09-2020
Another case of full code cache: ### TRACE 1: RNG seed = -6591978369021407795 (0xa4849699636b8dcd) [299.556s][warning][codecache] CodeCache is full. Compiler has been disabled. [299.556s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize= CodeCache: size=102400Kb used=102378Kb max_used=102392Kb free=22Kb bounds [0x000000baf9290000, 0x000000baff690000, 0x000000baff690000] total_blobs=60298 nmethods=17963 adapters=8855 compilation: disabled (not enough contiguous free space left) stopped_count=1, restarted_count=0 full_count=0 #> #> WARNING: switching log to verbose mode, #> because error is complained #> # ERROR: Failed runs: 1 of 1 #> #> SUMMARY: Following errors occured #> during test execution: #> # ERROR: Failed runs: 1 of 1 ----------System.err:(64/3839)---------- Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-7" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-10" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-21" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-28" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-29" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-12" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-11" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-26" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-27" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-32" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-20" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-31" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-19" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-34" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-17" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-5" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-33" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-2" Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "Thread-8" java.lang.NoClassDefFoundError: Could not initialize class java.util.Formatter at java.base/java.lang.String.format(String.java:3282) at nsk.share.test.LazyFormatString.toString(LazyFormatString.java:37) at java.base/java.lang.String.valueOf(String.java:3368) at java.base/java.io.PrintWriter.println(PrintWriter.java:836) at nsk.share.Log.printExceptionToString(Log.java:300) at nsk.share.Log.complain(Log.java:410) at vm.mlvm.share.Env.complain(Env.java:173) at vm.mlvm.share.MlvmTestExecutor.launch(MlvmTestExecutor.java:246) at vm.mlvm.share.MlvmTestExecutor.launch(MlvmTestExecutor.java:186) at vm.mlvm.share.MlvmTestExecutor.launch(MlvmTestExecutor.java:157) at vm.mlvm.share.MlvmTest.launch(MlvmTest.java:335) at vm.mlvm.meth.stress.compiler.deoptimize.Test.main(Test.java:172) 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:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:830)
03-11-2019
currently problem-listed due to this bug: vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/Test.java vmTestbase/vm/mlvm/meth/func/java/throwException/Test.java vmTestbase/vm/mlvm/meth/func/jdi/breakpointOtherStratum/Test.java vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java vmTestbase/vm/mlvm/meth/stress/compiler/i2c_c2i/Test.java vmTestbase/vm/mlvm/meth/stress/compiler/sequences/Test.java vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java vmTestbase/vm/mlvm/meth/stress/java/sequences/Test.java vmTestbase/vm/mlvm/meth/stress/jdi/breakpointInCompiledCode/Test.java
31-01-2019
JDK-8079646 description has the idea on how it can be fixed: JDK-8208255 adds stack oveflow checking to MLVM MethodHandle graph generation routines to prevent MLVM tests from failing with StackOverflowError. However, when running tests with the fix of the bug mentioned above, the tests are failing with CodeCache overflows: Java HotSpot(TM) 64-Bit Server VM warning: CodeHeap 'non-nmethods' is full. Compiler has been disabled. Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code heap size using -XX:ProfiledCodeHeapSize= Java HotSpot(TM) 64-Bit Server VM warning: CodeHeap 'non-profiled nmethods' is full. Compiler has been disabled. Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code heap size using -XX:NonProfiledCodeHeapSize= Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has been disabled. Java HotSpot(TM) Client VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= In order to fix this, the following can be done: - Add CodeCache free space checking methods into WhiteBox API (JDK-8065152) - Use these methods during estimating max. size of MethodHandle graph - Add CodeCache overflow checks when calling the MethodHandle graph (as we do with stack checking) - Add a test, which artifically provokes CodeCache overflow and expects it Failing tests are: vm/mlvm/meth/stress/compiler/sequences vm/mlvm/meth/stress/compiler/i2c_c2i vm/mlvm/**/breakpoint*
31-01-2019
ILW = missing code coverage for MethodHandles; stress mlvm tests w/ small CodeCache; none = MLH = P4
13-04-2016
ILW=Test need to be more resilient, common problem, none=LHH=P4
15-09-2014