RFR(S): 8203425: assert(is_Loop()) failed: invalid node class

[Tobias Hartmann]

Hi Nils,

looks good to me.

Best regards,
Tobias

On 08.06.2018 14:05, Nils Eliasson wrote:
> Hi,
> 
> After much testing the patch suggested doesn't still fail in some cases. Until I have a better patch
> I suggest we revert JDK-8203215. The original problem only manifested itself together with barriers
> in ZGC, and a workaround is in place.
> 
> Webrev: http://cr.openjdk.java.net/~neliasso/8203425.02/webrev.01/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8203425
> 
> If I can get a quick review, I will push today.
> 
> Regards,
> 
> Nils
> 
> 
> On 2018-05-23 14:14, Nils Eliasson wrote:
>> Hi,
>>
>> This is a follow up to JDK-8203215 that caused failures in testing.
>>
>> JDK-8203215 added a call to igvn.optimize after beautify_loops to handle phi-nodes that have lost
>> their loop edge and now produce loop invariant data. In testing a failure came up - the
>> igvn.optimize call can sometimes eliminate a loop node when the phis are all invariant.
>>
>> When fixing this I observed that a loop might be removed, and that another region that is a subset
>> of the first is selected as new loop, and then there might be new loop invariant phis (not observed).
>>
>> This change introduces a fix point iteration for beautify_loops, until no more loop structure
>> changes has been made. This might sound expensive but In practice beautify-loops is called one
>> additional time at first insertion of loop-nodes. I have seen one case of cascading loop
>> reductions when beautify_loops is called three times. The upside is that we reach fix point for
>> PhaseIdealLoop faster since these changes would guarantee to trigger a major change in next
>> iteration instead.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8203425
>>
>> http://cr.openjdk.java.net/~neliasso/8203425/webrev.01/
>>
>> Regards,
>>
>> Nils Eliasson
>>
>