[9, 8u40] RFR (S): 8058148: MaxNodeLimit and LiveNodeCountInliningCutoff should be increased
vladimir.x.ivanov at oracle.com
Wed Nov 19 19:26:40 UTC 2014
Thanks for the review, Vladimir.
On 11/19/14, 3:44 AM, Vladimir Kozlov wrote:
> I don't like to have different changes. I think to be able change
> maxnodelimit dynamically is good for jdk9 too. For example, for compiler
> control project.
Ok, I'm fine with either choice. I though about making MaxNodeLimit
controllable through CompilerOracle, but didn't see much value in it. If
you think it could be useful, I'm fine with integrating custom limits
into 9 as well.
> Did you run all benchmarks in performance infrastructure for jdk9
> changes? There should be no regression.
Yes, I ran all benchamrks, but I'll let Sergey Kuksenko comment on that.
He has a promotion run in progress with new limits to doublecheck
nothing is broken.
> On 11/18/14 11:40 AM, Vladimir Ivanov wrote:
>> 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 ) 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
>> the change.
>> Testing: Octane benchmarks w/ new limits.
>> Best regards,
>> Vladimir Ivanov
More information about the hotspot-compiler-dev