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.
This was fixed long ago. The failure was caused by an unused LoadNNode that was not removed during IGVN because it was kept alive by a MemBarAcquireNode. I don't think the failures that now showed up in the AOT nightlies are related (but probably similar). Please file a new bug. It could be that we need another special case in Node::has_special_unique_user().
We've seen a manifestation of this bug in our nightly:
--------------- T H R E A D ---------------
Current thread (0x00007f2a18898800): JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=5000, stack(0x00007f28c0d8f000,0x00007f28c0e90000)]
C2:1076165 118246 ! 4 java.lang.invoke.InnerClassLambdaMetafactory::buildCallSite (156 bytes)
Stack: [0x00007f28c0d8f000,0x00007f28c0e90000], sp=0x00007f28c0e8ac40, free space=1007k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x1445f82] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x162
V [libjvm.so+0x1446c7f] VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f
V [libjvm.so+0x9679bd] report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
V [libjvm.so+0x11cc477] PhaseChaitin::yank_if_dead_recurse(Node*, Node*, Block*, Node_List*, Node_List*) [clone .part.55]+0x127
V [libjvm.so+0x11d0db3] PhaseChaitin::post_allocate_copy_removal()+0xee3
V [libjvm.so+0x7a0963] PhaseChaitin::Register_Allocate()+0xac3
V [libjvm.so+0x8e8128] Compile::Code_Gen()+0x3e8
V [libjvm.so+0x8eb98c] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x121c
V [libjvm.so+0x754602] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x2d2
V [libjvm.so+0x8f6bab] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x40b
V [libjvm.so+0x8f7988] CompileBroker::compiler_thread_loop()+0x2d8
V [libjvm.so+0x13b1b69] JavaThread::thread_main_inner()+0x1c9
V [libjvm.so+0x13b1dd0] JavaThread::run()+0x1d0
V [libjvm.so+0x1139c12] java_start(Thread*)+0xf2
C [libpthread.so.0+0x7df3] start_thread+0xc3
Added graphs. The problem is caused by the following steps:
1) A volatile field access adds a LoadNNode (35) to the graph that is connected to a MemBarAcquireNode (37) to prevent following loads from floating up past. The result of the load is used by a StoreNNode (44) (see 'graph_after_parsing.png').
2) During optimization the StoreNNode (44) is removed because a following StoreNNode (55) writes to the same memory location. The LoadNNode (35) is now useless but still connected to the MemBarAcquireNode (see 'graph_after_IGVN.png').
3) During matching a loadConP_load (9) is added together with a MachConstantBaseNode (10) to compute the address for the LoadNNode (see 'graph_before_reg_alloc.png').
4) During register allocation the assert in 'PhaseChaitin::yank_if_dead_recurse' is hit because a dead MachConstantBaseNode is not expected at this point.
The unused LoadNNode (35) should have been removed during IGVN. However, the corresponding optimization in 'MemBarNode::Ideal()' does not apply because at this point the LoadNNode (35) is still connected to the StoreNNode (44). After removing the StoreNNode (44) the MemBarAcquireNode (37) should be added to the IGVN worklist to be processed again.
I was able to reproduce the bug. Unfortunately it only occurs after the 30-40 minutes it takes to startup and run weblogic+medrec with UTE. Will again try to replay compilation with the newly generated replay file and the .jars gathered by UTE.
The assert is hit while compiling com.sun.org.apache.xerces.internal.jaxp.DefaultValidationErrorHandler::<init>. I was finally able to replay the compilation on the same machine by specifying the .jar files manually (without using the buildreplayjars command which is not working due to JDK-8015848). Still not able to reproduce the bug after multiple runs.
Tried to replay compilation. Fails due to JDK-8015848.