RFR(S): 8222738: Shenandoah: assert(is_Proj()) failed when running cometd benchmarks
Roman Kennke
rkennke at redhat.com
Wed Apr 24 09:03:24 UTC 2019
Looks good to me, thanks!
Roman
> 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