JDK-8131129 : Attempt to define a duplicate BMH$Species class
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-07-14
  • Updated: 2017-09-07
  • Resolved: 2015-11-09
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
8u101Fixed 9 b93Fixed
Related Reports
Blocks :  
JDK-8136967 - revert all changes applied to obtain information about 8131129
Blocks :  
JDK-8136931 - more fine-grained condition checking for BMH species creation
Relates :  
JDK-8142363 - Remove LFMultiThreadCachingTest.java from windows problem list
Relates :  
JDK-8139925 - Problem list LFMultiThreadCachingTest.java on windows
Sub Tasks
JDK-8136931 :  
more fine-grained condition checking for BMH species creation - Closed
JDK-8136967 :  
revert all changes applied to obtain information about 8131129 - Closed
Description
The test

test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

has failed with a linkage error in nightly testing.
Comments
I'm taking care of the backport.
30-11-2015
Review thread with summary explanation: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-October/036109.html
28-10-2015
Agreed!
28-10-2015
@Michael the change I proposed to fix racy publication of not fully initialized species class would also fix this problem then, because it registers a class in cache only after its <clinit> finished successfully. No rolling back needed.
26-10-2015
Some archaeological activity in testing logs later I believe I found the reason. There used to be the occasional occurrence of test failures of the following shape: java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic at java.lang.invoke.MethodHandleStatics.newInternalError(MethodHandleStatics.java:120) at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:214) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:188) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:177) at java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:84) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1655) at java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1600) at java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:777) at java.lang.invoke.BoundMethodHandle$Factory.makeCbmhCtor(BoundMethodHandle.java:817) at java.lang.invoke.BoundMethodHandle$Factory.makeCtors(BoundMethodHandle.java:772) at java.lang.invoke.BoundMethodHandle$SpeciesData.<init>(BoundMethodHandle.java:347) at java.lang.invoke.BoundMethodHandle$SpeciesData.getForClass(BoundMethodHandle.java:411) at java.lang.invoke.BoundMethodHandle$Species_IL7.<clinit>(Species_IL7) at sun.misc.Unsafe.ensureClassInitialized(Native Method) at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:718) at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) at TestMethods$4.getMH(TestMethods.java:180) at TestMethods.getTestCaseMH(TestMethods.java:548) at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic at java.lang.invoke.MemberName.makeAccessException(MemberName.java:873) at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:212) ... 25 more Caused by: java.lang.NoSuchMethodError: java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;ILjava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; at java.lang.invoke.MethodHandleNatives.resolve(Native Method) at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:962) at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:987) ... 26 more Caused by: java.lang.VirtualMachineError: out of space in CodeCache for method handle intrinsic ... 29 more java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" at sun.misc.Unsafe.defineClass(Native Method) at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) at TestMethods$4.getMH(TestMethods.java:180) at TestMethods.getTestCaseMH(TestMethods.java:548) at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" at sun.misc.Unsafe.defineClass(Native Method) at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:363) at java.lang.invoke.LambdaFormEditor.makeArgumentCombinationForm(LambdaFormEditor.java:631) at java.lang.invoke.LambdaFormEditor.filterArgumentForm(LambdaFormEditor.java:612) at java.lang.invoke.MethodHandles.filterArgument(MethodHandles.java:2667) at java.lang.invoke.MethodHandles.filterArguments(MethodHandles.java:2654) at TestMethods$4.getMH(TestMethods.java:180) at TestMethods.getTestCaseMH(TestMethods.java:548) at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:80) at LFMultiThreadCachingTest$$Lambda$5/21979926.run(Unknown Source) at java.lang.Thread.run(Thread.java:745) STATUS:Failed.STATUS:Failed.STATUS:Failed.`main' threw exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" `main' threw exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" `main' threw exception: java.lang.InternalError: java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,Object,int,Object,Object,Object,Object,Object,Object,Object,MemberName)Object/invokeStatic java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_IL7" at sun.misc.Unsafe.defineClass(Native Method) at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) This beautifully confirms one of the suspicions mentioned, namely that something goes wrong in the dynamic extent of a Species class initialisation. Proposed solution: guard species class initialization and roll back the cache entry in case any exception is thrown, i.e., augment BMH.Factory.generateConcreteBMHClass() as follows: try { UNSAFE.ensureClassInitialized(bmhClass); } catch (Throwable t) { // If anything awkward happens during initialization of the BMH species, the class may have registered // itself with the SpeciesData cache already by virtue of invoking SpeciesData.getForClass(). This must // be rolled back before throwing the exception or error. SpeciesData.rollbackCache(types); throw t; } LFMultiThreadCachingTest may well encounter several code cache overflows during its execution, but the code in its doTest() method reveals that only the first one seen during wrap-up after test execution will be logged. The old logs in which the above stack trace (and similar ones) occurred did not yet have this partial output suppression. JDK-8140511 is filed to address this and enable full debugging output again.
26-10-2015
Peter: more feedback on your remarks, this time: "Is it possible that exception reporting from VM is just wrong and produced "duplicate class definition" error because of scarce space in CodeCache (haven't studied the VM code yet)?" I don't think so. The LinkageError is thrown in SystemDictionary::check_constraints(), and is quite clearly associated with an unexpectedly succeeding invocation of find_class().
23-10-2015
Peter: getting back to this comment of yours: "The <clinit> of that subclass calls back BMH$Species.getForClass passing itself to it which registers new (non-placeholder) SpeciesData in the CACHE, thus effectively publishing the class. But that class is just in the middle of <clinit> attempting to assign the new SpeciesData to it's SPECIES_DATA static field. A thread could thus obtain it from CACHE and use the class while SPECIES_DATA is still null." I agree this could be a race. I also agree that this is likely not the reason for the issue at hand: the synchronisation on d and subsequent invocation of lookupCache() in SD.get() should take care of that. The race would surface in the form of a NPE when the still-null SpeciesData is dereferenced. Let's keep this in mind. Right? As for the issue at hand, I'm not sure about your second remark: "If <clinit> somehow fails (maybe because of VM issues such as full CodeCache or something else), then you end-up with VM defined class that is half-initialized and not registered in SpeciesData CACHE. Next time someone requests the same species, a class with same name is attempted to be defined." If something awkward happened during <clinit> execution, that would be noticeable in the form of an exception or error. While we do observe code cache overflows, these are "always" (in all occurrences of this issue I've seen) about other classes than the one for which the duplicate definition is attempted, so this class's cache entry cannot be corrupted. Moreover, the <clinit> for the BMH species is simple: it merely places the types string and type of the BMH species on the stack, invokes SpeciesData.getForClass(), and places the result in the static field SPECIES_DATA. The control flow below getForClass() has some complexity in the constructor of SpeciesData, but it does not contain anything that could lead to a recursive invocation of the species generator. What am I missing? Continuing to stare down stack traces.
23-10-2015
Michael, just one more thought... The code - as is - is relying on generated and defined MBH subclass to successfully execute the <clinit>. If <clinit> somehow fails (maybe because of VM issues such as full CodeCache or something else), then you end-up with VM defined class that is half-initialized and not registered in SpeciesData CACHE. Next time someone requests the same species, a class with same name is attempted to be defined.
23-09-2015
Peter, what you describe is one of several suspicions I've had in the meantime - thanks for confirming. :-) I've added more fine-grained error checking to track down what is misbehaving.
23-09-2015
Just one thought... Michael said: New suspicion - the course of events might be as follows: 1. thread 1 attempts to get the LF for the given signature 2. thread 1 registers the data in the class registry 3. thread 1 notes the code cache is full and aborts 4. thread 2 attempts to get the LF for the given (same) signature 5. thread 2 notes the data is already registered and throws the duplicate definition error The excerpt below suggests this might indeed be the case. ...The excerpt above shows two exceptions from two threads: - 1st: LinkageError "duplicate class definition" from Unsafe.defineClass - 2nd: VirtualMachineError "Out of space in CodeCache for adapters" from Unsafe.defineAnonymousClass So the question is how could defineAnonymousClass interfere with "duplicate class definition" of a named class. If the 2nd exception is just an indication of the state VM was in at that time (scarce space in CodeCache) then where is the exception from the 1st attempt of the named class definition that failed because of scarce space in CodeCache (point #3 in Michael's list of events)? Is it possible that exception reporting from VM is just wrong and produced "duplicate class definition" error because of scarce space in CodeCache (haven't studied the VM code yet)? While looking at BHM code, I think I found a data race in BMH not directly related to this issue, but here it is anyway: BMH$Factory.generateConcreteBMHClass generates bytecode for BMH subclass and then defines it as a named class and forces it's initialization. The <clinit> of that subclass calls back BMH$Species.getForClass passing itself to it which registers new (non-placeholder) SpeciesData in the CACHE, thus effectively publishing the class. But that class is just in the middle of <clinit> attempting to assign the new SpeciesData to it's SPECIES_DATA static field. A thread could thus obtain it from CACHE and use the class while SPECIES_DATA is still null. I don't know how serious this race is, but it could be fixed with the following simple patch: http://cr.openjdk.java.net/~plevart/jdk9-dev/BMH.race/webrev.01/
23-09-2015
Mach 5 has seen this same failure 7 of the last 58 build/test runs and 0/42 prior to that. http://java.se.oracle.com/mach5/view/All/job/9-dev-tier1-windows-i586-failuresHistory/Failure_History/
21-09-2015
New suspicion - the course of events might be as follows: 1. thread 1 attempts to get the LF for the given signature 2. thread 1 registers the data in the class registry 3. thread 1 notes the code cache is full and aborts 4. thread 2 attempts to get the LF for the given (same) signature 5. thread 2 notes the data is already registered and throws the duplicate definition error The excerpt below suggests this might indeed be the case. A thread with name "Thread-1643" of 2 threads has thrown exception: java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_JJIIFJLI4JJDIIDLDILI4DI3LDLFDI3LI3DI3JDLFIIFDIFILJI3JILFIILIL3I3LLIFDJJLLI3LILIIJIIJIFIIJI3FJIDLI4FI8" at sun.misc.Unsafe.defineClass(Native Method) at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:396) at java.lang.invoke.LambdaFormEditor.bindArgumentForm(LambdaFormEditor.java:459) at java.lang.invoke.LambdaFormEditor.bindArgumentI(LambdaFormEditor.java:410) at java.lang.invoke.BoundMethodHandle.bindArgumentI(BoundMethodHandle.java:101) at java.lang.invoke.MethodHandles.insertArgumentPrimitive(MethodHandles.java:2391) at java.lang.invoke.MethodHandles.insertArguments(MethodHandles.java:2372) at TestMethods$6.getMH(TestMethods.java:236) at TestMethods.getTestCaseMH(TestMethods.java:548) at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:88) at java.lang.Thread.run(Thread.java:745) java.lang.Error: One ore more threads have thrown unexpected exceptions. See log. at LFMultiThreadCachingTest.doTest(LFMultiThreadCachingTest.java:116) at jdk.testlibrary.Utils.filterException(Utils.java:351) 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:144) 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:502) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) at java.lang.Thread.run(Thread.java:745) FAILED. Caused by One ore more threads have thrown unexpected exceptions. See log. Tested LF caching feature with MethodHandles.permuteArguments method. A thread with name "Thread-1645" of 2 threads has thrown exception: java.lang.InternalError: identity_J=Lambda(a0:L/SpeciesData<J>,a1:D,a2:D,a3:I,a4:L,a5:L,a6:I,a7:I,a8:F,a9:I,a10:I,a11:I,a12:I,a13:I,a14:I,a15:I,a16:I,a17:L,a18:J,a19:D,a20:I,a21:I,a22:F,a23:F,a24:I,a25:J,a26:I,a27:I,a28:J,a29:I,a30:I,a31:I,a32:I,a33:I,a34:L,a35:D,a36:I,a37:I,a38:D,a39:F,a40:I,a41:I,a42:I,a43:D,a44:F,a45:I,a46:I,a47:I,a48:I,a49:I,a50:D,a51:J,a52:I,a53:I,a54:I,a55:D,a56:I,a57:I,a58:D,a59:I,a60:I,a61:I,a62:I,a63:F,a64:D,a65:D,a66:D,a67:F,a68:L,a69:I,a70:I,a71:I,a72:I,a73:I,a74:I,a75:I,a76:L,a77:I,a78:D,a79:I,a80:I)=>{ t81:J=BoundMethodHandle$Species_J.argJ0(a0:L);t81:J} 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:459) at java.lang.invoke.BoundMethodHandle.<init>(BoundMethodHandle.java:56) at java.lang.invoke.BoundMethodHandle$Species_J.<init>(Species_J) at java.lang.invoke.BoundMethodHandle$Species_J.copyWith(Species_J) at java.lang.invoke.MethodHandles.dropArguments(MethodHandles.java:2460) at com.oracle.testlibrary.jsr292.Helper.addTrailingArgs(Helper.java:172) at TestMethods.methodHandleGenerator(TestMethods.java:651) 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:88) at java.lang.Thread.run(Thread.java:745) 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 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:120) at jdk.testlibrary.Utils.filterException(Utils.java:351) 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:144) 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:502) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.InternalError: identity_J=Lambda(a0:L/SpeciesData<J>,a1:D,a2:D,a3:I,a4:L,a5:L,a6:I,a7:I,a8:F,a9:I,a10:I,a11:I,a12:I,a13:I,a14:I,a15:I,a16:I,a17:L,a18:J,a19:D,a20:I,a21:I,a22:F,a23:F,a24:I,a25:J,a26:I,a27:I,a28:J,a29:I,a30:I,a31:I,a32:I,a33:I,a34:L,a35:D,a36:I,a37:I,a38:D,a39:F,a40:I,a41:I,a42:I,a43:D,a44:F,a45:I,a46:I,a47:I,a48:I,a49:I,a50:D,a51:J,a52:I,a53:I,a54:I,a55:D,a56:I,a57:I,a58:D,a59:I,a60:I,a61:I,a62:I,a63:F,a64:D,a65:D,a66:D,a67:F,a68:L,a69:I,a70:I,a71:I,a72:I,a73:I,a74:I,a75:I,a76:L,a77:I,a78:D,a79:I,a80:I)=>{ t81:J=BoundMethodHandle$Species_J.argJ0(a0:L);t81:J} 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:459) at java.lang.invoke.BoundMethodHandle.<init>(BoundMethodHandle.java:56) at java.lang.invoke.BoundMethodHandle$Species_J.<init>(Species_J) at java.lang.invoke.BoundMethodHandle$Species_J.copyWith(Species_J) at java.lang.invoke.MethodHandles.dropArguments(MethodHandles.java:2460) at com.oracle.testlibrary.jsr292.Helper.addTrailingArgs(Helper.java:172) at TestMethods.methodHandleGenerator(TestMethods.java:651) 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:88) ... 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 822 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:144) 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:502) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) at java.lang.Thread.run(Thread.java:745)
02-09-2015
Intermediate status after some analysis by [~vlivanov] and myself: * Could not reproduce. Still, the error occurs now and then in testing since at least 1.9.0b00. * The synchronisation logic in place looks OK (code reading). * Class loading logic in VM looks OK (code reading) - loading occurs in synchronised contexts only, so likely no VM-internal synchronisation issues. * The method LambdaForm.shortenSignature(), which might have wrongly returned the same result for different inputs, looks OK (code reading, stress testing with large numbers of randomly generated signatures).
03-08-2015
The following code tries to avoid duplicate definitions of BMH species, but it seems it's not enough: jdk/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java: private static SpeciesData get(String types) { // Acquire cache lock for query. SpeciesData d = lookupCache(types); if (!d.isPlaceholder()) return d; synchronized (d) { // Use synch. on the placeholder to prevent multiple instantiation of one species. // Creating this class forces a recursive call to getForClass. if (lookupCache(types).isPlaceholder()) Factory.generateConcreteBMHClass(types); } // Reacquire cache lock. d = lookupCache(types); // Class loading must have upgraded the cache. assert(d != null && !d.isPlaceholder()); return d; }
14-07-2015
java.lang.LinkageError: loader (instance of <bootloader>): attempted duplicate class definition for name: "java/lang/invoke/BoundMethodHandle$Species_JJIIFJLI4JJDIIDLDILI4DI3LDLFDI3LI3DI3JDLFIIFDIFILJI3JILFIILIL3I3LLIFDJJLLI3LILIIJIIJIFIIJI3FJIDLI4FI8" at sun.misc.Unsafe.defineClass(Native Method) at java.lang.invoke.BoundMethodHandle$Factory.generateConcreteBMHClass(BoundMethodHandle.java:715) at java.lang.invoke.BoundMethodHandle$SpeciesData.get(BoundMethodHandle.java:401) at java.lang.invoke.BoundMethodHandle$SpeciesData.extendWith(BoundMethodHandle.java:388) at java.lang.invoke.LambdaFormEditor.newSpeciesData(LambdaFormEditor.java:396) at java.lang.invoke.LambdaFormEditor.bindArgumentForm(LambdaFormEditor.java:459) at java.lang.invoke.LambdaFormEditor.bindArgumentI(LambdaFormEditor.java:410) at java.lang.invoke.BoundMethodHandle.bindArgumentI(BoundMethodHandle.java:101) at java.lang.invoke.MethodHandles.insertArgumentPrimitive(MethodHandles.java:2391) at java.lang.invoke.MethodHandles.insertArguments(MethodHandles.java:2372) at TestMethods$6.getMH(TestMethods.java:236) at TestMethods.getTestCaseMH(TestMethods.java:548) at LFMultiThreadCachingTest.lambda$doTest$0(LFMultiThreadCachingTest.java:88) at java.lang.Thread.run(Thread.java:745)
14-07-2015