JDK-8058733 : [TESTBUG] java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java and LFMultiThreadCachingTest.java failed on some platforms due to java.lang.VirtualMachineError
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 8u40,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-09-18
  • Updated: 2016-03-29
  • Resolved: 2014-10-10
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 8 JDK 9
8u40Fixed 9 b36Fixed
Related Reports
Relates :  
JDK-8058536 - java/lang/instrument/NativeMethodPrefixAgent.java fails due to VirtualMachineError: out of space in CodeCache for method handle intrinsic
Description
TESTFAIL:java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java
TESTFAIL:java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

After JDK-8058293, we still see these tests fail on some platforms due to: 
java.lang.VirtualMachineError: out of space in CodeCache for adapters

From the log:
----------System.out:(6/265)----------
-Dseed=4103170949823617197
-DtestLimit=2000
CodeCache: size=32768Kb used=32284Kb max_used=32284Kb free=483Kb
 bounds [0x40f28000, 0x42eb0000, 0x42f28000]
 total_blobs=16753 nmethods=6199 adapters=10485
 compilation: disabled (not enough contiguous free space left)
----------System.err:(1791/90864)----------
...
Tested LF caching feature with MethodHandles.guardWithTest method.
java.lang.VirtualMachineError: out of space in CodeCache for adapters
	at sun.misc.Unsafe.defineAnonymousClass(Native Method)
	at java.lang.invoke.InvokerBytecodeGenerator.loadAndInitializeInvokerClass(InvokerBytecodeGenerator.java:282)
	at java.lang.invoke.InvokerBytecodeGenerator.loadMethod(InvokerBytecodeGenerator.java:274)
	at java.lang.invoke.InvokerBytecodeGenerator.generateLambdaFormInterpreterEntryPoint(InvokerBytecodeGenerator.java:1282)
	at java.lang.invoke.LambdaForm.getPreparedForm(LambdaForm.java:674)
	at java.lang.invoke.LambdaForm.prepare(LambdaForm.java:599)
	at java.lang.invoke.MethodHandle.<init>(MethodHandle.java:459)
	at java.lang.invoke.BoundMethodHandle.<init>(BoundMethodHandle.java:56)
	at java.lang.invoke.BoundMethodHandle$Species_I.<init>(Species_I)
	at java.lang.invoke.BoundMethodHandle$Species_I.copyWith(Species_I)
	at java.lang.invoke.MethodHandles.dropArguments(MethodHandles.java:2513)
	at com.oracle.testlibrary.jsr292.Helper.addTrailingArgs(Helper.java:172)
	at TestMethods.methodHandleGenerator(TestMethods.java:644)
	at TestMethods.access$200(TestMethods.java:41)
	at TestMethods$9.getMH(TestMethods.java:319)
	at TestMethods.getTestCaseMH(TestMethods.java:541)
	at LFSingleThreadCachingTest.doTest(LFSingleThreadCachingTest.java:62)
	at LambdaFormTestCase.runTests(LambdaFormTestCase.java:98)
	at LFSingleThreadCachingTest.main(LFSingleThreadCachingTest.java:76)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:745)
...
STATUS:Failed.`main' threw exception: java.lang.Error: 794 of 1989 test cases FAILED! Rerun the test with the same "-Dseed=" option as in the log file!
Comments
Google is also seeing this test fail in jdk8 on linux, about 8% of the time. So this problem is not fixed! Log snippet follows: Non-critical exception caught becuse of code cache size is not enough to run all test cases. java.lang.Error: One ore more threads have thrown VirtualMachineError caused by code cache overflow. See log. at LFMultiThreadCachingTest.doTest(LFMultiThreadCachingTest.java:119) at jdk.testlibrary.Utils.filterException(Utils.java:304) at com.oracle.testlibrary.jsr292.CodeCacheOverflowProcessor.runMHTest(CodeCacheOverflowProcessor.java:70) at LambdaFormTestCase$TestRun.doIteration(LambdaFormTestCase.java:124) at jdk.testlibrary.TimeLimitedRunner.call(TimeLimitedRunner.java:71) at LambdaFormTestCase.runTests(LambdaFormTestCase.java:193) at LFMultiThreadCachingTest.main(LFMultiThreadCachingTest.java:143) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.InternalError: identity_I=Lambda(a0:L/SpeciesData<I>,a1:J,a2:I,a3:L,a4:I,a5:I,a6:L,a7:I,a8:D,a9:L,a10:F,a11:F,a12:I,a13:I,a14:I,a15:I,a16:J,a17:I,a18:L,a19:L,a20:L,a21:L,a22:I,a23:I,a24:I,a25:I,a26:L,a27:F,a28:I,a29:I,a30:F,a31:I,a32:D,a33:I,a34:I,a35:L,a36:D,a37:J,a38:L,a39:I,a40:J,a41:F,a42:I,a43:I,a44:I,a45:D,a46:L,a47:D,a48:I,a49:I,a50:L,a51:I,a52:I,a53:D,a54:F,a55:I,a56:F,a57:I,a58:I,a59:I,a60:I,a61:I,a62:I,a63:F,a64:I,a65:L,a66:I,a67:I,a68:I,a69:I,a70:D,a71:L,a72:I,a73:I,a74:L,a75:I,a76:J,a77:I,a78:I,a79:I,a80:I,a81:I,a82:I,a83:I,a84:I,a85:I,a86:I,a87:I,a88:I,a89:L,a90:I,a91:I,a92:I,a93:I,a94:L,a95:I,a96:I,a97:L,a98:I,a99:I,a100:I,a101:J,a102:I,a103:I)=>{ t104:I=BoundMethodHandle$Species_I.argI0(a0:L);t104:I} at java.lang.invoke.MethodHandleStatics.newInternalError(MethodHandleStatics.java:127) at java.lang.invoke.LambdaForm.compileToBytecode(LambdaForm.java:660) at java.lang.invoke.LambdaForm.prepare(LambdaForm.java:635) at java.lang.invoke.MethodHandle.<init>(MethodHandle.java:461) at java.lang.invoke.BoundMethodHandle.<init>(BoundMethodHandle.java:56) at java.lang.invoke.BoundMethodHandle$Species_I.<init>(Species_I) at java.lang.invoke.BoundMethodHandle$Species_I.copyWith(Species_I) at java.lang.invoke.MethodHandles.dropArguments(MethodHandles.java:2460) at com.oracle.testlibrary.jsr292.Helper.addTrailingArgs(Helper.java:172) at TestMethods.methodHandleGenerator(TestMethods.java:632) at TestMethods.access$300(TestMethods.java:41) at TestMethods$7.getMH(TestMethods.java:269) at TestMethods.getTestCaseMH(TestMethods.java:548) at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:87) ... 1 more Caused by: java.lang.VirtualMachineError: out of space in CodeCache for adapters at sun.misc.Unsafe.defineAnonymousClass(Native Method) at java.lang.invoke.InvokerBytecodeGenerator.loadAndInitializeInvokerClass(InvokerBytecodeGenerator.java:284) at java.lang.invoke.InvokerBytecodeGenerator.loadMethod(InvokerBytecodeGenerator.java:276) at java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(InvokerBytecodeGenerator.java:618) at java.lang.invoke.LambdaForm.compileToBytecode(LambdaForm.java:654) ... 13 more java.lang.Error: 1 of 1570 test cases FAILED! Rerun the test with the same "-Dseed=" option as in the log file! at LambdaFormTestCase$TestRun.checkPassed(LambdaFormTestCase.java:147) at LambdaFormTestCase.runTests(LambdaFormTestCase.java:198) at LFMultiThreadCachingTest.main(LFMultiThreadCachingTest.java:143) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(Thread.java:745)
29-03-2016
The test marked as fixed in 2014, however it is still failing intermittently: It failed 6 times on our new build&test system - Mach 5. For example: http://java.se.oracle.com/mach5/view/All/job/9-dev-tier1-windows-i586/280/testReport/junit/java_lang_invoke_LFCaching_LFMultiThreadCachingTest/java/LFMultiThreadCachingTest/ According to the page, the test failed 4 times in the last 30 runs. Stability: 86 % Test: java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java.LFMultiThreadCachingTest Error: ... 1 more Caused by: java.lang.VirtualMachineError: Out of space in CodeCache for adapters at sun.misc.Unsafe.defineAnonymousClass(Native Method) at java.lang.invoke.InvokerBytecodeGenerator.loadAndInitializeInvokerClass(InvokerBytecodeGenerator.java:283) at java.lang.invoke.InvokerBytecodeGenerator.loadMethod(InvokerBytecodeGenerator.java:275) at java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(InvokerBytecodeGenerator.java:617) at java.lang.invoke.LambdaForm.compileToBytecode(LambdaForm.java:654)
28-09-2015
http://cr.openjdk.java.net/~kshefov/8058733/webrev.02
09-10-2014
Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-October/029009.html
08-10-2014
Will try to use also NonNMethodCodeHeapSize flag to define iteration number.
08-10-2014
I have found "NonNMethodCodeHeapSize"
08-10-2014
[~vlivanov], As I have understood JDK-8043304 if for JDK 9 only, not for jdk 8u40. What option should I use to set/get "NonMethodCodeHeapSize"?
08-10-2014
[~kshefov], yes, it relates to segmented code cache (JDK-8043304).
08-10-2014
There is other failure now: CodeHeap 'non-nmethods': size=7988Kb used=7498Kb max_used=7498Kb free=489Kb bounds [0x00007ff5bcfff000, 0x00007ff5bd75f000, 0x00007ff5bd7cc000] CodeHeap 'profiled nmethods': size=118888Kb used=3735Kb max_used=3839Kb free=115152Kb bounds [0x00007ff5bd7cc000, 0x00007ff5bdb8c000, 0x00007ff5c4be6000] CodeHeap 'non-profiled nmethods': size=118888Kb used=3060Kb max_used=3070Kb free=115828Kb bounds [0x00007ff5c4be6000, 0x00007ff5c4ee6000, 0x00007ff5cc000000] total_blobs=4582 nmethods=2803 adapters=1686 compilation: disabled (not enough contiguous free space left) It says: 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= But JDK 9 b32 does not know option "-XX:ProfiledCodeHeapSize". Is it a new feature?
08-10-2014
I have an idea to take ReservedCodeCacheSize value by HotSpotDiagnosticMXBean and limit the number of iterations in the test according to the cache size.
08-10-2014
There is not hotspot change planned for that at the moment. As Vladimir Ivanov mentioned in the comment above the solution should probably be to increase the code cache size for these tests.
07-10-2014
I'm also seeing these failures, and in JPRT too. Do these tests need additional XX options to increase the CodeCache or are we waiting for a hotspot change? It would be good to exclude the tests until the issues are resolved as it makes it harder to see other failures.
07-10-2014
Looks similar to JDK-8058536
19-09-2014
The tests shouldn't rely on default code cache size and either explicitly specify large enough size or reduce number of tests. Until JVM starts to unload MethodHandle adapters, there's no other way to reduce code cache usage.
18-09-2014