JDK-8232030 : HelloDynamic.java fails with latest Graal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-10-08
  • Updated: 2019-10-24
  • Resolved: 2019-10-18
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 14
14 b20Fixed
Related Reports
Relates :  
JDK-8231606 - _method_ordering is not set during CDS dynamic dump time
Description
If I update JDK with the latest Graal, I get this crash, and it is reproducible:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error[0.382s][info][class,load] java.util.concurrent.ConcurrentHashMap$CollectionView source: shared objects file
 (open/src/hotspot/share/oops/instanceKlass.cpp:3610), pid=15270, tid=15283
#  guarantee(length == methods()->length()) failed: invalid method ordering length
#
# JRE version: Java(TM) SE Runtime Environment (14.0) (fastdebug build 14-internal+0-2019-10-04-1908127.dean.long.dev0)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 14-internal+0-2019-10-04-1908127.dean.long.dev0, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xdd4c74]  InstanceKlass::verify_on(outputStream*)+0x844
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/72e605a88500 User: ccheung Date: 2019-10-18 16:18:08 +0000
18-10-2019
During CDS dynamic dumping and during the loading of a class whose super class has default methods, the method_ordering is not set correctly after merging in the default methods. A simple fix is in the merge_in_new_methods() of defaultMethods.cpp to include the dynamic dumping condition when setting up the merged_ordering array. bash-4.2$ hg diff src/hotspot/share/classfile/defaultMethods.cpp diff --git a/src/hotspot/share/classfile/defaultMethods.cpp b/src/hotspot/share/classfile/defaultMethods.cpp --- a/src/hotspot/share/classfile/defaultMethods.cpp +++ b/src/hotspot/share/classfile/defaultMethods.cpp @@ -1012,7 +1012,7 @@ klass->class_loader_data(), new_size, NULL, CHECK); // original_ordering might be empty if this class has no methods of its own - if (JvmtiExport::can_maintain_original_method_order() || DumpSharedSpaces) { + if (JvmtiExport::can_maintain_original_method_order() || Arguments::is_dumping_archive()) { merged_ordering = MetadataFactory::new_array<int>( klass->class_loader_data(), new_size, CHECK); }
17-10-2019
ILW = HLM = P3
15-10-2019
if (JvmtiExport::can_maintain_original_method_order() || ((UseSharedSpaces || DumpSharedSpaces) && length != 0)) { guarantee(length == methods()->length(), "invalid method ordering length"); If we have JvmtiExport::can_maintain_original_method_order() == true but length == 0, do we still want this block to execute? The "&& length != 0" only applies to the UseSharedSpaces || DumpSharedSpaces part. Also is there any reason to set _method_ordering to an empty array instead of NULL?
08-10-2019
I am able to reproduce this with a jdk repo with version 5b5de2618756 (about 1 days old as of now): cd test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive jtreg -vmoptions:'-ea -esa -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -Djvmci.Compiler=graal -XX:+TieredCompilation' HelloDynamic.java # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/instanceKlass.cpp:3610 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (open/src/hotspot/share/oops/instanceKlass.cpp:3610), pid=29559, tid=29761 # guarantee(length == methods()->length()) failed: invalid method ordering length ... (gdb) frame 6 #6 0x00007ffff60517d7 in InstanceKlass::verify_on (this=0x800b630a0, st=0x7ffff0000930) at /jdk2/tmp/dean/open/src/hotspot/share/oops/instanceKlass.cpp:3610 3610 guarantee(length == methods()->length(), "invalid method ordering length"); (gdb) p length $2 = 0 (gdb) p _methods $3 = (Array<Method*> *) 0x800baf078 (gdb) p _methods->_length $4 = 6 (gdb) p _name->print() Symbol: 'jdk/vm/ci/hotspot/HotSpotJavaType' count 65535$6 = void (gdb) p _method_ordering $7 = (Array<int> *) 0x800ac10c0 (gdb) p *_method_ordering $8 = {<MetaspaceObj> = {}, _length = 0, _data = {0}} V [libjvm.so+0x120eaac] InstanceKlass::verify_on(outputStream*)+0x81c V [libjvm.so+0x15a7ef4] Klass::append_to_sibling_list()+0x34 V [libjvm.so+0x1affae6] SystemDictionary::add_to_hierarchy(InstanceKlass*, Thread*)+0x36 V [libjvm.so+0x1b06a9d] SystemDictionary::define_instance_class(InstanceKlass*, Thread*)+0x45d V [libjvm.so+0x1b06f88] SystemDictionary::find_or_define_instance_class(Symbol*, Handle, InstanceKlass*, Thread*)+0x208 V [libjvm.so+0x1b09501] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x3f1 V [libjvm.so+0x1b07e96] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x906 V [libjvm.so+0x1b08203] SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*)+0x93 V [libjvm.so+0x1b0869c] SystemDictionary::resolve_super_or_fail(Symbol*, Symbol*, Handle, Handle, bool, Thread*)+0x31c V [libjvm.so+0x1b08bef] SystemDictionary::load_shared_class(InstanceKlass*, Handle, Handle, ClassFileStream const*, Thread*)+0xef V [libjvm.so+0x1b094cf] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x3bf V [libjvm.so+0x1b07e96] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x906 V [libjvm.so+0x1b08203] SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*)+0x93 V [libjvm.so+0x1b0869c] SystemDictionary::resolve_super_or_fail(Symbol*, Symbol*, Handle, Handle, bool, Thread*)+0x31c V [libjvm.so+0x1b08bef] SystemDictionary::load_shared_class(InstanceKlass*, Handle, Handle, ClassFileStream const*, Thread*)+0xef V [libjvm.so+0x1b094cf] SystemDictionary::load_instance_class(Symbol*, Handle, Thread*)+0x3bf V [libjvm.so+0x1b07e96] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x906 V [libjvm.so+0x1b08203] SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*)+0x93 V [libjvm.so+0x1b0a690] SystemDictionary::resolve_or_fail(Symbol*, bool, Thread*)+0x70 V [libjvm.so+0x146e6b2] HotSpotJVMCI::compute_offsets(Thread*)+0x1a2 V [libjvm.so+0x14c1d09] JVMCIRuntime::initialize(JVMCIEnv*)+0x169 V [libjvm.so+0x14c6abd] JVMCIRuntime::compile_method(JVMCIEnv*, JVMCICompiler*, methodHandle const&, int)+0x12d V [libjvm.so+0xdfedeb] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xf0b V [libjvm.so+0xdff3f8] CompileBroker::compiler_thread_loop()+0x4f8 V [libjvm.so+0x1b69a62] JavaThread::thread_main_inner()+0x2c2 V [libjvm.so+0x1b71992] JavaThread::run()+0x2b2 V [libjvm.so+0x1b6f0a6] Thread::call_run()+0xf6 V [libjvm.so+0x18750be] thread_native_entry(Thread*)+0x10e
08-10-2019