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