[9, 8u40] RFR (S): 8058148: MaxNodeLimit and LiveNodeCountInliningCutoff should be increased

[Vladimir Ivanov]

https://bugs.openjdk.java.net/browse/JDK-8058148
    9: http://cr.openjdk.java.net/~vlivanov/8058148/webrev.9.00
8u40: http://cr.openjdk.java.net/~vlivanov/8058148/webrev.8u40.00

LambdaForm sharing implementation (JEP-210 [1]) changes LambdaForm 
bytecode shape. Bytecode size increases and it causes more pressure on 
JIT-compiler. It leads to severe peak performance regressions due to C2 
compilation bailouts when the compiler hits MaxNodeLimit & 
LiveNodeCountInliningCutoff.

My experiments w/ Octane/Nashorn shows that bumping 
LiveNodeCountInliningCutoff from 20k to 40k (2x) and MaxNodeLimit from 
80k to 240k (3x) are enough to get rid of C2 bailouts.

It's safe to increase LiveNodeCountInliningCutoff, since it affects only 
incremental inlining, which is enabled only for JSR292.

Regarding MaxNodeLimit, loop opts depend on it. So, there's a risk its 
change can negatively affect time-to-performance and peak performance 
due to loops over-optimization.

I prepared different fixes for 9 and 8u40.

For 8u40, I took a conservative route and bump the limit only for 
methods w/ invokedynamic and MethodHandle.invoke* usages.
I keep per-compilation MaxNodeLimit value and update it when indy 
instruction or MH.invoke* methods are encountered.

For 9, I propose to simply bump the limit. Performance team is fine with 
the change.

Testing: Octane benchmarks w/ new limits.

Thanks!

Best regards,
Vladimir Ivanov