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