[9] RFR (S): 8059241: Incremental inlining is too hot when compiling Nashorn/Octane

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Fri Apr 24 23:43:04 UTC 2015


According to -XX:+CITime, C2 spends too much time in incremental 
inlining (see the bug for the numbers).

2 observations:
   * PhaseRemoveUseless is performed too frequently (for every 
successful inlining tree) and it becomes more expensive the larger IR is 
(linear complexity);

   * Inlining happens in smaller steps the closer live node count is to 

The fix is two-fold:

  (1) Reduce PhaseRemoveUseless frequency: inline in larger chunks until 
IR size LiveNodeCountInliningCutoff, then eliminate dead nodes.

  (2) Have a relatively small (10%) gap between 
LiveNodeCountInliningCutoff and actual limit when inlining step is 
finished to give the algorithm some space to "breath" (hence smallest 
inlining chunk produce at least 10%*LiveNodeCountInliningCutoff nodes).

It leads to significant reduction in incremental inline times (e.g. 
Box2D: Prune Useless: 22s -> 2.2s).

Testing: octane/nashorn (w/ -XX:+CITime)

Best regards,
Vladimir Ivanov

More information about the hotspot-compiler-dev mailing list