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

[Vladimir Kozlov]

+1

Vladimir K

On 1/29/20 5:45 AM, Vladimir Ivanov wrote:
> 
>> 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.
>>