[9] RFR(S): 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node

Tobias Hartmann tobias.hartmann at oracle.com
Wed Nov 23 13:20:42 UTC 2016


Hi,

please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8168996
http://cr.openjdk.java.net/~thartmann/8168996/webrev.00/

We crash in the register allocator because of an "unexpected yanked node". The problem is that there is a MemBarAcquire node from a volatile object field load that keeps otherwise dead LoadN nodes alive (see graph at [1]). This is very similar to JDK-8048879 [2] with the difference that the MemBarAcquire -> DecodeN is not directly connected to the LoadN but there is a Phi in between. This Phi was created by the split if optimization by splitting the original LoadN node through a memory Phi and thus creating multiple LoadN nodes connected to a new data Phi. The Phi becomes dead later and is only kept alive by the MemBarAcquire node.

The code in MemBarNode::Ideal() should take care of such a scenario by rewiring and finally removing the MemBar if the precedence input has only one user. The problem is that this code is never executed because the MemBar node is not added to the IGVN worklist after the users of the DecodeN node become dead. I fixed this by adding a special case to Node::has_special_unique_user() similar to what I did for Load nodes in the fix for JDK-8048879.

I was not able to write a regression test for this but can reproduce the problem reliably with replay compilation which generates a very complex graph.

Tested with replay compilation, JPRT and RBT (running).

Thanks,
Tobias

[1] C2 graph before RA:

 1974	LoadN	=== _  876  1016  [[ 1993 ]]  @java/lang/Class:exact+124 * [narrow], name=security, idx=23; Volatile! #narrowoop: java/lang/SecurityManager * !orig=[1169] !jvms: MemberName::testFlags @ bci:7 MemberName::testAllFlags @ bci:3 MemberName::isConstructor @ bci:3 MethodHandles$Lookup::checkMethod @ bci:14 MethodHandles$Lookup::getDirectMethodCommon @ bci:4 MethodHandles$Lookup::getDirectMethod @ bci:14 MethodHandles$Lookup::findStatic @ bci:23 InnerClassLambdaMetafactory::buildCallSite @ bci:137
 1973	LoadN	=== _  875  1016  [[ 1993 ]]  @java/lang/Class:exact+124 * [narrow], name=security, idx=23; Volatile! #narrowoop: java/lang/SecurityManager * !orig=[1169] !jvms: MemberName::testFlags @ bci:7 MemberName::testAllFlags @ bci:3 MemberName::isConstructor @ bci:3 MethodHandles$Lookup::checkMethod @ bci:14 MethodHandles$Lookup::getDirectMethodCommon @ bci:4 MethodHandles$Lookup::getDirectMethod @ bci:14 MethodHandles$Lookup::findStatic @ bci:23 InnerClassLambdaMetafactory::buildCallSite @ bci:137
 1972	LoadN	=== _  874  1016  [[ 1993 ]]  @java/lang/Class:exact+124 * [narrow], name=security, idx=23; Volatile! #narrowoop: java/lang/SecurityManager * !orig=[1169] !jvms: MemberName::testFlags @ bci:7 MemberName::testAllFlags @ bci:3 MemberName::isConstructor @ bci:3 MethodHandles$Lookup::checkMethod @ bci:14 MethodHandles$Lookup::getDirectMethodCommon @ bci:4 MethodHandles$Lookup::getDirectMethod @
 1993	Phi	===  1983  1972  1973  1974  [[ 894 ]]  #narrowoop: java/lang/SecurityManager * !orig=[1971],[1169] !jvms: MethodHandles$Lookup::checkMethod @ bci:17 MethodHandles$Lookup::getDirectMethodCommon @ bci:4 MethodHandles$Lookup::getDirectMethod @ bci:14 MethodHandles$Lookup::findStatic @ bci:23 InnerClassLambdaMetafactory::buildCallSite @ bci:137
 894	DecodeN	=== _  1993  [[ 599 ]]  #java/lang/SecurityManager *  Oop:java/lang/SecurityManager * !jvms: MemberName::clone @ bci:1 MemberName$Factory::resolve @ bci:1 MemberName$Factory::resolveOrFail @ bci:4 MethodHandles$Lookup::resolveOrFail @ bci:44 MethodHandles$Lookup::findStatic @ bci:6 InnerClassLambdaMetafactory::buildCallSite @ bci:137
 599	MemBarAcquire	===  892  1  893  1  1  894  [[ 890  365 ]]  !jvms: String::startsWith @ bci:50 String::startsWith @ bci:3 MethodHandles$Lookup::checkMethodName @ bci:3 MethodHandles$Lookup::resolveOrFail @ bci:19 MethodHandles$Lookup::findStatic @ bci:6 InnerClassLambdaMetafactory::buildCallSite @ bci:137

[2] https://bugs.openjdk.java.net/browse/JDK-8048879


More information about the hotspot-compiler-dev mailing list