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

[Vladimir Kozlov]

On 11/19/14 11:26 AM, 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

Looks good.

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

Good. Lets wait results.

Thanks,
Vladimir

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