RFR(XS): CTW: C2 compilation fails with "malformed control flow"

Roland Westrelin rwestrel at redhat.com
Wed Jan 29 08:42:40 UTC 2020


http://cr.openjdk.java.net/~roland/8237951/webrev.00/

CatchNode::Value() makes the fallthrough path of a virtual or interface
call dead if the receiver is null. This failure occurs because the
fallthrough is erroneously killed during CCP. When CCP is executed, the
type of the receiver is first set to top which causes CatchNode::Value()
to make the fallthrough path dead then the type of the receiver changes
to non null but the CatchNode is not reprocessed by CCP. That happens
because:

1758         // If we changed the receiver type to a call, we need to revisit
1759         // the Catch following the call.  It's looking for a non-NULL
1760         // receiver to know when to enable the regular fall-through path
1761         // in addition to the NullPtrException path
1762         if (m->is_Call()) {
1763           for (DUIterator_Fast i2max, i2 = m->fast_outs(i2max); i2 < i2max; i2++) {
1764             Node* p = m->fast_out(i2);  // Propagate changes to uses
1765             if (p->is_Proj() && p->as_Proj()->_con == TypeFunc::Control && p->outcnt() == 1) {
1766               worklist.push(p->unique_out());

the ProjNode has more than one use: a Load is pinned there. I could
write a test case that causes a Load to be pinned on a Proj after a Call
but couldn't have the test case trigger the failure (most likely because
node processing order during CCP matters). The fix is to enqueue the
CatchNode even if p doesn't have a single use.

Note: this triggered with Shenandoah but is not specific to Shenandoah.

Roland.



More information about the hotspot-compiler-dev mailing list