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

[Vladimir Ivanov]

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

Looks good.

Best regards,
Vladimir Ivanov

> 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.
>