RFR(XS): 8229450: C2 compilation fails with assert(found_sfpt) failed

Tobias Hartmann tobias.hartmann at oracle.com
Tue Sep 3 09:25:27 UTC 2019


Hi,

On 03.09.19 08:20, Liu Xin wrote:
> https://cr.openjdk.java.net/~xliu/8229450/04/webrev/

I think this still needs some refactoring:
- In line 1352, you are casting a pointer to boolean. You can simply move the check to line 1347 and
initialize out_le depending on 'is_inner_of_stripmined_loop'. Or why not just update prevdom there?
- The comments in 1195 - 1198 should be moved to line 1347 because they are unrelated to the method.
- Use "Node* var" instead of "Node *var" for new code (yes, existing code uses different formats).

> 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. 

I leave this for Roland to answer, he's the loop strip mining expert :)

Best regards,
Tobias



More information about the hotspot-compiler-dev mailing list