JDK-8048879 : "unexpected yanked node" opto/postaloc.cpp:139
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u31,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-07-01
  • Updated: 2020-10-16
  • Resolved: 2014-08-19
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
8u40Fixed 9 b29Fixed
Related Reports
Relates :  
JDK-8147014 - VM Crashes with assert(false) failed: unexpected yanked node
Description
#  Internal Error (/opt/jprt/T/P1/061924.amurillo/s/src/share/vm/opto/postaloc.cpp:139), pid=10405, tid=9
#  assert(false) failed: unexpected yanked node

When running bigapps/Weblogic+medrec/stability
Comments
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().
29-03-2016
output before crash: orig_old: 670 loadN === _ 633 2436 [[]] narrowoop: java/lang/SecurityManager * !jvms: DirectMethodHandle::make @ bci:52 MethodHandles$Lookup::getDirectMethodCommon @ bci:201 MethodHandles$Lookup::getDirectMethod @ bci:14 MethodHandles$Lookup::findStatic @ bci:23 InnerClassLambdaMetafactory::buildCallSite @ bci:137 old: 670 loadN === _ 633 2436 [[]] narrowoop: java/lang/SecurityManager * !jvms: DirectMethodHandle::make @ bci:52 MethodHandles$Lookup::getDirectMethodCommon @ bci:201 MethodHandles$Lookup::getDirectMethod @ bci:14 MethodHandles$Lookup::findStatic @ bci:23 InnerClassLambdaMetafactory::buildCallSite @ bci:137
28-03-2016
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)] Current CompileTask: 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
28-03-2016
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.
15-08-2014
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.
09-07-2014
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.
08-07-2014
Tried to replay compilation. Fails due to JDK-8015848.
03-07-2014
RULE bigapps/Weblogic+medrec/stability Crash Internal Error ...postaloc.cpp...assert(false) failed: unexpected yanked node
01-07-2014
ILW=HLM=P3
01-07-2014