RFR(S): 8205515: assert(opcode == Op_RangeCheck) failed: no other if variant here
Roland Westrelin
rwestrel at redhat.com
Fri Jun 29 08:14:50 UTC 2018
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