JDK-8085965 : VM hangs in C2Compiler
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-06-08
  • Updated: 2017-11-03
  • Resolved: 2015-06-17
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
8u45Fixed 9 b72Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Compiler thread hangs with the following stack trace when VM is in the synchronizing state:

(gdb) where
#0  0x00007fb7db705179 in Klass::subklass (this=0x101343828)
#1  0x00007fb7db4555c5 in find_finalizable_subclass (k=0x101343828)
#2  Dependencies::find_finalizable_subclass (k=0x101343828)
#3  0x00007fb7db3638ee in ciInstanceKlass::has_finalizable_subclass(this=0x7fb7d40a78e0)
#4  0x00007fb7db8828fb in Parse::call_register_finalizer(this=0x7fb7c49f67a0)
#5  0x00007fb7db882fb9 in Parse::return_current (this=0x101343828, value=0x0)
#6  0x00007fb7db88f526 in Parse::do_one_bytecode (this=0x101343828)
#7  0x00007fb7db8817d8 in Parse::do_one_block (this=0x7fb7c49f67a0)
#8  0x00007fb7db881a57 in Parse::do_all_blocks (this=0x7fb7c49f67a0)
#9  0x00007fb7db885fe9 in Parse::Parse (this=0x7fb7c49f67a0, caller=<value optimized out>, parse_method=<value optimized out>, expected_uses=15617)
#10 0x00007fb7db3384e8 in ParseGenerator::generate (this=0x7fb78c173120, jvms=0x7fb7a40191f0)
#11 0x00007fb7db4aea36 in Parse::do_call (this=0x7fb7c49f6bc0)
#12 0x00007fb7db88f5aa in Parse::do_one_bytecode (this=0x101343828)
#13 0x00007fb7db8817d8 in Parse::do_one_block (this=0x7fb7c49f6bc0)
#14 0x00007fb7db881a57 in Parse::do_all_blocks (this=0x7fb7c49f6bc0)
#15 0x00007fb7db885fe9 in Parse::Parse (this=0x7fb7c49f6bc0, caller=<value optimized out>, parse_method=<value optimized out>, expected_uses=15617)
#16 0x00007fb7db3384e8 in ParseGenerator::generate (this=0x7fb78c173030, jvms=0x7fb7a40190e0)
#17 0x00007fb7db4aea36 in Parse::do_call (this=0x7fb7c49f6fe0)
#18 0x00007fb7db88f5aa in Parse::do_one_bytecode (this=0x101343828)
#19 0x00007fb7db8817d8 in Parse::do_one_block (this=0x7fb7c49f6fe0)
#20 0x00007fb7db881a57 in Parse::do_all_blocks (this=0x7fb7c49f6fe0)
#21 0x00007fb7db885fe9 in Parse::Parse (this=0x7fb7c49f6fe0, caller=<value optimized out>, parse_method=<value optimized out>, expected_uses=15617)
#22 0x00007fb7db3384e8 in ParseGenerator::generate (this=0x7fb78c172f40, jvms=0x7fb7a4018f60)
#23 0x00007fb7db3e8dfa in Compile::Compile (this=<value optimized out>, ci_env=<value optimized out>, compiler=0x7fb7d40f8ad0,    target=<value optimized out>, osr_bci=-1, subsume_loads=<value optimized out>, do_escape_analysis=true, eliminate_boxing=true)
#24 0x00007fb7db336eb8 in C2Compiler::compile_method (this=0x7fb7d40f8ad0, env=0x7fb7c49f89f0, target=0x17e0710, entry_bci=-1)
#25 0x00007fb7db3f343a in CompileBroker::invoke_compiler_on_method (task=0x7fb7741f7740)
#26 0x00007fb7db3f43e6 in CompileBroker::compiler_thread_loop ()
#27 0x00007fb7db9a786f in JavaThread::thread_main_inner (this=0x7fb7d4101800)
#28 0x00007fb7db9a799c in JavaThread::run (this=0x7fb7d4101800)
#29 0x00007fb7db85bde8 in java_start (thread=0x7fb7d4101800)
#30 0x0000003785007851 in start_thread ()
#31 0x0000003784ce767d in clone ()

Comments
In JDK8, CMSClassUnloadingEnabled option which is used to control the class-unloading in CMS, was enabled by default. One phase of the class-unloading which is common to the other collectors as well is performed only when ClassUnloading option is enabled. So when -Xnoclassgc or -XX:-ClassUnloading are specified on the command line, classes get unloaded but that common step (that updates subkalsses/siblings links) gets skipped which corrupts the class hierarchy links causing hangs and crashes.
10-06-2015

Analysis of a Java Thread hang: (gdb) where #0 Dependencies::find_finalizable_subclass (k=0x1010eec30) #1 0x00007f4a8ba35c8a in Dependencies::find_finalizable_subclass (k=0x1001acec0) #2 0x00007f4a8ba35c8a in Dependencies::find_finalizable_subclass (k=0x10000a000) #3 0x00007f4a8ba3df11 in check_has_no_finalizable_subclasses (changes=<optimized out>, ctxk=<optimized out>) #4 Dependencies::DepStream::check_klass_dependency (this=0x7f49e2a6f950, changes=0x0) #5 0x00007f4a8c005e0b in check_dependency (this=<optimized out>) #6 nmethod::check_all_dependencies (this=0x7f4a75270390) #7 0x00007f4a8b944aee in CodeCache::mark_for_deoptimization (changes=...) #8 0x00007f4a8c28339a in Universe::flush_dependents_on (dependee=...) #9 0x00007f4a8c20b216 in SystemDictionary::add_to_hierarchy (k=..., __the_thread__=0x7f4a0800f800) #10 0x00007f4a8c21371d in SystemDictionary::define_instance_class (k=..., __the_thread__=0x7f4a0800f800) #11 0x00007f4a8c217881 in SystemDictionary::resolve_from_stream (class_name=0x7f4a109a8610, class_loader=..., protection_domain=..., st=0x7f49e2a700b0, verify=<optimized out>, __the_thread__=0x7f4a0800f800) #12 0x00007f4a8bda9d25 in jvm_define_class_common (env=0x7f4a0800fa40, name=<optimized out>, loader=0x7f49e2a70458, buf=0x7f4a1098c140 "\312\376\272\276", len=1356, pd=0x0, source=0x7f4a8c4337aa "__JVM_DefineClass__", verify=1 '\001', #13 0x00007f4a8bdaa5ac in JVM_DefineClass (env=0x7f4a0800fa40, name=0x7f49e2a702a0 "sun/reflect/GeneratedSerializationConstructorAccessor256", loader=0x7f49e2a70458, buf=0x7f4a1098c140 "\312\376\272\276", len=1356, pd=0x0) #14 0x00007f4a8c28b1f0 in Unsafe_DefineClass_impl (env=0x7f4a0800fa40, name=0x7f49e2a70438, data=0x7f49e2a70440, offset=0, length=1356, #15 0x00007f4a8c2900f7 in Unsafe_DefineClass (env=0x7f4a0800fa40, unsafe=<optimized out>, name=0x7f49e2a70438, data=0x7f49e2a70440, offset=0, VM hangs while going over a circular siblings list: (super and subklasses chain built from the core file) super class sun/reflect/SerializationConstructorAccessorImpl - 0x1001acec0 |--subklasses chain 0x1010eec30-sun/reflect/GeneratedSerializationConstructorAccessor232-> 0x1010ef030-sun/reflect/GeneratedSerializationConstructorAccessor231-> 0x1010ef430-sun/reflect/GeneratedSerializationConstructorAccessor230-> 0x1010ef830-sun/reflect/GeneratedSerializationConstructorAccessor229-> 0x1010efc30-sun/reflect/GeneratedSerializationConstructorAccessor228-> 0x1010f0030-sun/reflect/GeneratedSerializationConstructorAccessor227-> 0x1010f0430-sun/reflect/GeneratedSerializationConstructorAccessor226-> 0x1010f0830-sun/reflect/GeneratedSerializationConstructorAccessor225-> 0x1010f0c30- sun/reflect/GeneratedSerializationConstructorAccessor224-> 0x1010f1030-sun/reflect/GeneratedSerializationConstructorAccessor223-> 0x1010f1430-sun/reflect/GeneratedSerializationConstructorAccessor222-> 0x1010f1830-sun/reflect/GeneratedSerializationConstructorAccessor221-> 0x1010f1c30-sun/reflect/GeneratedSerializationConstructorAccessor220-> 0x1010f2030-sun/reflect/GeneratedSerializationConstructorAccessor219-> 0x1010f2430- sun/reflect/GeneratedSerializationConstructorAccessor218-> 0x1010f2830-sun/reflect/GeneratedSerializationConstructorAccessor217-> 0x10110b830-sun/reflect/GeneratedMethodAccessor94-> 0x1010e8430-sun/reflect/GeneratedSerializationConstructorAccessor256-> 0x1010e8830-sun/reflect/GeneratedSerializationConstructorAccessor255-> 0x1010e8c30-sun/reflect/GeneratedSerializationConstructorAccessor254-> 0x1010e9830-sun/reflect/GeneratedSerializationConstructorAccessor253-> 0x1010e9c30-sun/reflect/GeneratedSerializationConstructorAccessor252-> 0x1010ea030-sun/reflect/GeneratedSerializationConstructorAccessor251-> 0x1010ea430-sun/reflect/GeneratedSerializationConstructorAccessor250-> 0x1010ea830-sun/reflect/GeneratedSerializationConstructorAccessor249-> 0x1010eac30-sun/reflect/GeneratedSerializationConstructorAccessor248-> 0x1010eb030-sun/reflect/GeneratedSerializationConstructorAccessor247-> 0x1010eb430-sun/reflect/GeneratedSerializationConstructorAccessor246-> 0x1010eb830-sun/reflect/GeneratedSerializationConstructorAccessor245-> 0x1010ebc30-sun/reflect/GeneratedSerializationConstructorAccessor244-> 0x1010ec030-sun/reflect/GeneratedSerializationConstructorAccessor243-> 0x1010ec430-sun/reflect/GeneratedSerializationConstructorAccessor242-> 0x1010ec830-sun/reflect/GeneratedSerializationConstructorAccessor241-> 0x1010ecc30-sun/reflect/GeneratedSerializationConstructorAccessor240-> 0x1010ed030-sun/reflect/GeneratedSerializationConstructorAccessor239-> 0x1010ed430-sun/reflect/GeneratedSerializationConstructorAccessor238-> 0x1010ed830-sun/reflect/GeneratedSerializationConstructorAccessor237-> 0x1010edc30-sun/reflect/GeneratedSerializationConstructorAccessor236-> 0x1010ee030-sun/reflect/GeneratedSerializationConstructorAccessor235-> 0x1010ee430-sun/reflect/GeneratedSerializationConstructorAccessor234-> 0x1010ee830-sun/reflect/GeneratedSerializationConstructorAccessor233-> 0x1010eec30-sun/reflect/GeneratedSerializationConstructorAccessor232 The logs show: [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor216 0x000000010110b830] Important thing to note here is that at address 0x10110b830, GeneratedSerializationConstructorAccessor216 was unloaded and sun/reflect/GeneratedMethodAccessor94 got loaded into the system dictionary. But the link to GeneratedSerializationConstructorAccessor216 in the subclasses list was not updated after this class was unloaded, and that corrupted the subclasses chain.
10-06-2015

Should it be GC subcategory since this problem is not caused by JIT compiler but by class unloading?
08-06-2015