RFR(XS): 8229450: C2 compilation fails with assert(found_sfpt) failed
Liu Xin
navy.xliu at gmail.com
Tue Sep 3 06:20:01 UTC 2019
Hi, Roland and Robias,
Could you review this CR? I removed both ' -XX:+UseCountedLoopSafepoints'
and -XX:LoopStripMiningIter=1000'. they are pre-set by G1.
https://cr.openjdk.java.net/~xliu/8229450/04/webrev/
I have yet another proposal. Can I file a JBS issue to avoid a short
trip-counted loop from trip-mining?
My original program has a very short trip-counted loop. The upper-bound 4
is significantly smaller than LoopStripMiningIter.
Loop: N355/N216 limit_check counted [0,4),+1 (-1 iters) has_sfpt
strip_mined
This predicate doesn't consider trip-counted loop and its constant limit.
bool strip_mine_loop = LoopStripMiningIter > 1 && loop->_child == NULL &&
sfpt2->Opcode() == Op_SafePoint && !loop->_has_call
I think the original motivation for strip-mining is for GC? if a loop is
super hot, GCs don't have a chance to chime in.
A short trip-counted loop should not a problem for GC. if it has function
call, call node will have a safepoint itself.
thanks,
--lx
On Mon, Sep 2, 2019 at 8:38 AM Roland Westrelin <rwestrel at redhat.com> wrote:
>
>
> > I made mistake yesterday. I missed ' -XX:+UseCountedLoopSafepoints'.
>
> +UseCountedLoopSafepoints is the default and it's the only reasonable
> one so I don't think it's necessary to list it explicity. Regarding the
> code change: there is no need to mention bug numbers in the code. The
> source control system keeps track of that. There are existing cases
> where bugs are mentioned but they usually are in much older changes as
> it's no longer the current practice.
>
> My testing came back clean. You can consider this reviewed by me but you
> need another reviewer. I don't think we can count Tobias as a review (at
> least not yet). Once it's reviewed, I'll sponsor it.
>
> Roland.
>
More information about the hotspot-compiler-dev
mailing list