RFR(S): 8205515: assert(opcode == Op_RangeCheck) failed: no other if variant here

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Jun 29 18:00:02 UTC 2018


Thank you, Roland

Explanation and changes seems reasonable. Let me test it.

Thanks,
Vladimir

On 6/29/18 1:14 AM, Roland Westrelin wrote:
> 
> Hi Vladimir,
> 
>> Looks like this change cause an other crash for example in
>> gc/stress/gcbasher/TestGCBasherWithG1.java (no special flags are needed
>> - only ones in the test)
> 
> Thanks for testing. Here is an updated webrev:
> 
> http://cr.openjdk.java.net/~roland/8205515/webrev.01/
> 
> We have a block of regular predicates, followed by a block of profile
> predicates. For a data node that's above a loop, the logic tries to set
> its control as high as possible above the predicates.
> 
> The current logic looks for the profile predicate added at parse time
> then possibly for the predicate added at parse time and set the control
> of the data node above.
> 
> So with:
> 
> predicate added at parse time (with Opaque1 node)
> 
> profile predicate added at parse time (with Opaque1 node)
> 
> the data node would have control set above both predicates. With:
> 
> some predicate hoisted by loop predication
> some predicate hoisted by loop predication
> predicate added at parse time (with Opaque1 node)
> 
> profile predicate added at parse time (with Opaque1 node)
> 
> the data node would have control set right above the predicate added at
> parse time. And with:
> 
> some predicate hoisted by loop predication
> some predicate hoisted by loop predication
> predicate added at parse time (with Opaque1 node)
> 
> some profile predicate hoisted by loop predication
> some profile predicate hoisted by loop predication
> profile predicate added at parse time (with Opaque1 node)
> 
> the data node have control set right above the profile predicate added
> at parse time.
> 
> The problem is that sometimes, we have something like:
> 
> predicate added at parse time (with Opaque1 node)
> 
> if (a == null) { unc; } //some predicate hoisted by loop predication
> a = cast_not_null(a);   //data node control  dependent on hoisted predicate
> profile predicate added at parse time (with Opaque1 node)
> 
> then the compiler finds a dominating if (a == null) checks so the
> predicate can be removed but dominated_by() prevents the cast from
> moving up:
> 
> predicate added at parse time (with Opaque1 node)
> 
> a = cast_not_null(a);
> 
> profile predicate added at parse time (with Opaque1 node)
> 
> The current logic tries to set control of the cast above the first
> predicate which is incorrect.
> 
> Roland.
> 


More information about the hotspot-compiler-dev mailing list