RFR (S): 8059241: Incremental inlining is too hot when compiling Nashorn/Octane
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).
* PhaseRemoveUseless is performed too frequently (for every
successful inlining tree) and it becomes more expensive the larger IR is
* 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)
More information about the hotspot-compiler-dev