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

[Vladimir Ivanov]

http://cr.openjdk.java.net/~vlivanov/8059241/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8059241

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

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