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

[Vladimir Ivanov]

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.

Updated webrev:
   http://cr.openjdk.java.net/~vlivanov/8058148/webrev.9.01

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

Best regards,
Vladimir Ivanov

> On 11/18/14 11:40 AM, Vladimir Ivanov wrote:
>> 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