[9, 8u40] RFR (S): 8058148: MaxNodeLimit and LiveNodeCountInliningCutoff should be increased
vladimir.x.ivanov at oracle.com
Tue Nov 18 19:40:18 UTC 2014
LambdaForm sharing implementation (JEP-210 ) 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 &
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
Testing: Octane benchmarks w/ new limits.
More information about the hotspot-compiler-dev