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

[Sergey Kuksenko]

Sorry for delay, it was a long run. Just got results.
I executed all our promotion benchmarks.
I didn't see any regressions (except some weird cases, but here we 
should do more evaluation of that benchmarks itself).

So from performance point of view we are fine with that changes.

On 11/19/2014 10:26 PM, Vladimir Ivanov wrote:
> 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

-- 
Best regards,
Sergey Kuksenko