RFR(S): 8222738: Shenandoah: assert(is_Proj()) failed when running cometd benchmarks
Roland Westrelin
rwestrel at redhat.com
Thu Apr 18 15:46:13 UTC 2019
http://cr.openjdk.java.net/~roland/8222738/webrev.00/
The failure occurs because Shenandoah barrier expansion code tries to
expand a barrier whose control is a call node. That happens because one
of the uses of the barrier is a CastPP whose control dominates the call
while one its input is dependent on the return from the call. That, in
turn, occurs because the null check that the CastPP depends on is
optimized out by ConnectionGraph::optimize_ptr_compare() during EA. Then
the CastPP depends on another unrelated check and further optimization
of that check causes the CastPP control to change to something that
dominates the call.
Barrier expansion already has logic to deal with a barrier on the
control projection of a call because it's shared between the exception
and fallthrough paths. The fix I propose is to simply piggy back on that
logic (by making clones for the exception and fallthrough paths). The
conditions under which this particular bug shows up seem rare enough
that going with the simplest fix is the wisest thing to do even though
it causes a barrier to be emitted in both the exception path and the
fallthrough path when it's possible only one of those paths really needs
a barrier.
Roland.
More information about the hotspot-compiler-dev
mailing list