• Type: Bug
• Component: hotspot
• Sub-Component: compiler
• Affected Version: 8u40,9,10,11,12,13

• Priority: P4
• Status: Resolved
• Resolution: Fixed

• Submitted: 2014-11-28
• Updated: 2021-05-16
• Resolved: 2019-06-11

JDK 13	JDK 14
13 b25Fixed	14Fixed

The implementation in *load_extra_data()* has changed over the last few months (for JDK12/13) and may/should not manifest the problem any more. However, there might still be a potential problem (window) in *prepare_metadata()*, in the current JDK13 code base, where _PrepareExtraDataClosure_ will use the (now) fragile/raced (_SafepointSynchronize_) *safepoint_counter()*. The scenario would be that a safepoint has indeed started during *prepare_metadata()* but finishes after, without being detected. The test-case also uses the WhiteBox API to clean method data, via (_WhiteBox_) *clearMethodState()*. This would explain the (mal-) interaction with the previous implementation of *load_extra_data()*. 1. I would suggest that the issue is closed until manifested anew. 2. The Safepoint code/state should perhaps be scrutinized further to close the potential problem window. (Robbin has filed a new report: JDK-8225702) 13-06-2019 [~phedlin], I agree, and I am going to open a new bug for the assert on solaris and "fix" this one by unproblem-listing the test. as of addressing deficiencies of WhiteBox API, I'd really appreciate if you file an RFE and write up your concerns, ideas, etc. 11-06-2019 Sure there are problems here, but I think these are of more general nature related to the WhiteBox API, while the original issue is more directly related to the *extra_data_lock*. It might be better to open a new report to collect, track and address deficiencies in the WhiteBox API design (and implementation), rather than focusing on the individual asserts (that should no doubt be fixed). The primary goal should be to make the interaction between the WhiteBox and the VM both sound and robust (and that, I think, is a slightly larger task). But this particular issue can be closed. Thoughts? 10-06-2019 and on solaris-sparcv9-fastdebug, these tests hit the following assert: =============== DEBUG MESSAGE: MemberName required for invokeVirtual etc. ================ # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/macroAssembler_sparc.cpp:1473 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/scratch/opt/mach5/mesos/work_dir/ce2afd05-7e59-4fc6-8e22-904badf601db/workspace/open/src/hotspot/cpu/sparc/macroAssembler_sparc.cpp:1473), pid=31777, tid=2 # assert(false) failed: DEBUG MESSAGE: MemberName required for invokeVirtual etc. # # JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-internal+0-2019-06-05-1909010.igor.ignatyev.jdk) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-2019-06-05-1909010.igor.ignatyev.jdk, mixed mode, sharing, tiered, compressed oops, g1 gc, solaris-sparc) # Core dump will be written. Default location: /scratch/opt/mach5/mesos/work_dir/1630b6b8-8d96-4431-8aca-29ab9f622716/testoutput/test-support/jtreg_open_test_hotspot_jtreg_compiler_types_correctness/scratch/1/core or core.31777 # Unsupported internal testing APIs have been used. # An error report file with more information is saved as: # /scratch/opt/mach5/mesos/work_dir/1630b6b8-8d96-4431-8aca-29ab9f622716/testoutput/test-support/jtreg_open_test_hotspot_jtreg_compiler_types_correctness/scratch/1/hs_err_pid31777.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -XX:MaxRAMPercentage=2 -Xbootclasspath/a:. -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:CompileCommand=exclude,compiler.ty pes.correctness.execution.*::methodNotToCompile -XX:CompileCommand=dontinline,compiler.types.correctness.scenarios.Scenario::collectReturnType -XX:TypeProfileLevel=001 -XX:-UseTypeSpeculation compiler.types.co rrectness.CorrectnessTest PARAMETERS Host: <hostname>, Sparcv9 64 bit 3600 MHz, 56 cores, 58G, Oracle Solaris 11.3 SPARC Time: Wed Jun 5 20:16:29 2019 UTC elapsed time: 1 seconds (0d 0h 0m 1s) --------------- T H R E A D --------------- Current thread (0x0000000100137000): JavaThread "main" [_thread_in_Java, id=2, stack(0xffffffff7a400000,0xffffffff7a500000)] Stack: [0xffffffff7a400000,0xffffffff7a500000], sp=0xffffffff7a4fe800, free space=1018k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x20c4184] void VMError::report_and_die(int,const char*,const char*,void*,Thread*,unsigned char*,void*,void*,const char*,int,unsigned long)+0xac4 V [libjvm.so+0x20c3658] void VMError::report_and_die(Thread*,void*,const char*,int,const char*,const char*,void*)+0x38 V [libjvm.so+0x13fefd0] void report_vm_error(const char*,int,const char*,const char*,...)+0xf0 V [libjvm.so+0x1b0f9f0] void MacroAssembler::debug(char*,RegistersForDebugging*)+0x140 v ~StubRoutines::stop_subroutine J 60 java.lang.invoke.MethodHandle.linkToVirtual(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; java.base@13-internal (0 bytes) @ 0xffffffff69c0580c [0xffffffff69c05760+0 x00000000000000ac] J 60 java.lang.invoke.MethodHandle.linkToVirtual(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; java.base@13-internal (0 bytes) @ 0xffffffff69c057f0 [0xffffffff69c05760+0 x0000000000000090] j compiler.types.correctness.execution.TypeProfile.methodNotToCompile(Lcompiler/types/correctness/scenarios/Scenario;Lcompiler/types/correctness/hierarchies/TypeHierarchy$I;)Ljava/lang/Object;+2 J 307 c2 compiler.types.correctness.execution.TypeProfile.execute(Lcompiler/types/correctness/scenarios/Scenario;)V (58 bytes) @ 0xffffffff69c23c7c [0xffffffff69c23c00+0x000000000000007c] j compiler.types.correctness.execution.MethodHandleDelegate.execute(Lcompiler/types/correctness/scenarios/Scenario;)V+12 j compiler.types.correctness.CorrectnessTest.executeTest(Lcompiler/types/correctness/hierarchies/TypeHierarchy;Lcompiler/types/correctness/execution/Execution;Lcompiler/types/correctness/scenarios/Scenario;)Z +35 j compiler.types.correctness.CorrectnessTest.runTests(Lcompiler/types/correctness/scenarios/ProfilingType;)Z+432 j compiler.types.correctness.CorrectnessTest.main([Ljava/lang/String;)V+42 v ~StubRoutines::call_stub V [libjvm.so+0x1749528] void JavaCalls::call_helper(JavaValue*,const methodHandle&,JavaCallArguments*,Thread*)+0x438 V [libjvm.so+0x1823628] void jni_invoke_static(JNIEnv_*,JavaValue*,_jobject*,JNICallType,_jmethodID*,JNI_ArgumentPusher*,Thread*)+0x368 V [libjvm.so+0x1841ee4] jni_CallStaticVoidMethod+0x484 C [libjli.so+0x7920] JavaMain+0x880 C [libjli.so+0xd99c] ThreadJavaMain+0xc 05-06-2019 both compiler/types/correctness tests fail quite often on solaris-sparcv9 due to the following SEGV: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xffffffff6a804628, pid=35886, tid=2 # # JRE version: Java(TM) SE Runtime Environment (13.0) (build 13-internal+0-2019-06-05-1909010.igor.ignatyev.jdk) # Java VM: Java HotSpot(TM) 64-Bit Server VM (13-internal+0-2019-06-05-1909010.igor.ignatyev.jdk, mixed mode, sharing, tiered, compressed oops, g1 gc, solaris-sparc) # Problematic frame: # J 66 java.lang.invoke.MethodHandle.linkToVirtual(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; java.base@13-internal (0 bytes) @ 0xffffffff6a804628 [0xffffffff6a804600+0x0000000000000028] # # Core dump will be written. Default location: /opt/mach5/mesos/work_dir/7afd662b-0fc2-4074-bfdc-d11b7a59dd79/testoutput/test-support/jtreg_open_test_hotspot_jtreg_compiler_types_correctness/scratch/0/core or core.35886 # Unsupported internal testing APIs have been used. # An error report file with more information is saved as: # /opt/mach5/mesos/work_dir/7afd662b-0fc2-4074-bfdc-d11b7a59dd79/testoutput/test-support/jtreg_open_test_hotspot_jtreg_compiler_types_correctness/scratch/0/hs_err_pid35886.log Compiled method (c2) 1685 310 ! 4 compiler.types.correctness.execution.MethodHandleDelegate$MHScenario::run (43 bytes) total in heap [0xffffffff6a81a310,0xffffffff6a81a718] = 1032 relocation [0xffffffff6a81a468,0xffffffff6a81a478] = 16 constants [0xffffffff6a81a480,0xffffffff6a81a4a0] = 32 main code [0xffffffff6a81a4a0,0xffffffff6a81a580] = 224 stub code [0xffffffff6a81a580,0xffffffff6a81a5d0] = 80 oops [0xffffffff6a81a5d0,0xffffffff6a81a5f0] = 32 metadata [0xffffffff6a81a5f0,0xffffffff6a81a620] = 48 scopes data [0xffffffff6a81a620,0xffffffff6a81a688] = 104 scopes pcs [0xffffffff6a81a688,0xffffffff6a81a6e8] = 96 dependencies [0xffffffff6a81a6e8,0xffffffff6a81a6f0] = 8 handler table [0xffffffff6a81a6f0,0xffffffff6a81a708] = 24 nul chk table [0xffffffff6a81a708,0xffffffff6a81a718] = 16 Compiled method (c2) 1685 310 ! 4 compiler.types.correctness.execution.MethodHandleDelegate$MHScenario::run (43 bytes) total in heap [0xffffffff6a81a310,0xffffffff6a81a718] = 1032 relocation [0xffffffff6a81a468,0xffffffff6a81a478] = 16 constants [0xffffffff6a81a480,0xffffffff6a81a4a0] = 32 main code [0xffffffff6a81a4a0,0xffffffff6a81a580] = 224 stub code [0xffffffff6a81a580,0xffffffff6a81a5d0] = 80 oops [0xffffffff6a81a5d0,0xffffffff6a81a5f0] = 32 metadata [0xffffffff6a81a5f0,0xffffffff6a81a620] = 48 scopes data [0xffffffff6a81a620,0xffffffff6a81a688] = 104 scopes pcs [0xffffffff6a81a688,0xffffffff6a81a6e8] = 96 dependencies [0xffffffff6a81a6e8,0xffffffff6a81a6f0] = 8 handler table [0xffffffff6a81a6f0,0xffffffff6a81a708] = 24 nul chk table [0xffffffff6a81a708,0xffffffff6a81a718] = 16 Compiled method (c2) 1701 310 ! 4 compiler.types.correctness.execution.MethodHandleDelegate$MHScenario::run (43 bytes) total in heap [0xffffffff6a81a310,0xffffffff6a81a718] = 1032 relocation [0xffffffff6a81a468,0xffffffff6a81a478] = 16 constants [0xffffffff6a81a480,0xffffffff6a81a4a0] = 32 main code [0xffffffff6a81a4a0,0xffffffff6a81a580] = 224 stub code [0xffffffff6a81a580,0xffffffff6a81a5d0] = 80 oops [0xffffffff6a81a5d0,0xffffffff6a81a5f0] = 32 metadata [0xffffffff6a81a5f0,0xffffffff6a81a620] = 48 scopes data [0xffffffff6a81a620,0xffffffff6a81a688] = 104 scopes pcs [0xffffffff6a81a688,0xffffffff6a81a6e8] = 96 dependencies [0xffffffff6a81a6e8,0xffffffff6a81a6f0] = 8 handler table [0xffffffff6a81a6f0,0xffffffff6a81a708] = 24 nul chk table [0xffffffff6a81a708,0xffffffff6a81a718] = 16 # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -XX:MaxRAMPercentage=1 -Xbootclasspath/a:. -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:CompileCommand=exclude,compiler.ty pes.correctness.execution.*::methodNotToCompile -XX:CompileCommand=dontinline,compiler.types.correctness.scenarios.Scenario::collectReturnType -XX:TypeProfileLevel=122 -XX:+UseTypeSpeculation compiler.types.co rrectness.CorrectnessTest RETURN Host: Sparcv9 64 bit 4133 MHz, 63 cores, 64G, Oracle Solaris 11.3 SPARC Time: Wed Jun 5 19:59:59 2019 UTC elapsed time: 1 seconds (0d 0h 0m 1s) --------------- T H R E A D --------------- Current thread (0x0000000100128000): JavaThread "main" [_thread_in_Java, id=2, stack(0xffffffff7b000000,0xffffffff7b100000)] Stack: [0xffffffff7b000000,0xffffffff7b100000], sp=0xffffffff7b0ff200, free space=1020k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) J 63 java.lang.invoke.MethodHandle.linkToVirtual(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object; java.base@13-internal (0 bytes) @ 0xffffffff6a804628 [0xffffffff6a804600+0 x0000000000000028] j compiler.types.correctness.execution.TypeProfile.methodNotToCompile(Lcompiler/types/correctness/scenarios/Scenario;Lcompiler/types/correctness/hierarchies/TypeHierarchy$I;)Ljava/lang/Object;+2 J 385 c2 compiler.types.correctness.execution.TypeProfile.execute(Lcompiler/types/correctness/scenarios/Scenario;)V (58 bytes) @ 0xffffffff6a82adbc [0xffffffff6a82ad40+0x000000000000007c] j compiler.types.correctness.execution.MethodHandleDelegate.execute(Lcompiler/types/correctness/scenarios/Scenario;)V+12 j compiler.types.correctness.CorrectnessTest.executeTest(Lcompiler/types/correctness/hierarchies/TypeHierarchy;Lcompiler/types/correctness/execution/Execution;Lcompiler/types/correctness/scenarios/Scenario;)Z +35 j compiler.types.correctness.CorrectnessTest.runTests(Lcompiler/types/correctness/scenarios/ProfilingType;)Z+432 j compiler.types.correctness.CorrectnessTest.main([Ljava/lang/String;)V+42 v ~StubRoutines::call_stub V [libjvm.so+0xf71ed4] void JavaCalls::call_helper(JavaValue*,const methodHandle&,JavaCallArguments*,Thread*)+0x244 V [libjvm.so+0xff96d0] void jni_invoke_static(JNIEnv_*,JavaValue*,_jobject*,JNICallType,_jmethodID*,JNI_ArgumentPusher*,Thread*)+0x370 V [libjvm.so+0x100d750] jni_CallStaticVoidMethod+0x1c0 C [libjli.so+0x86dc] JavaMain+0x99c C [libjli.so+0x122fc] ThreadJavaMain+0xc 05-06-2019 Does anyone know how to reproduce this? I tried with 10 and 8u-cpu but couldn't get it to fail. 25-10-2017 test was quarantined by JDK-8066713 -> back to normal priority scheme ILW=internal test API causes assert;one test intermittently;none=MLH=P4 16-12-2014 ILW=internal test API causes assert;quite seldom;none=MLH=P4 + nightly P2 02-12-2014 Since MethodData is part of the profiling compiler code, this bug seems to be a compiler issue. 01-12-2014