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

[Vladimir Kozlov]

On 11/20/14 1:44 AM, Vladimir Ivanov wrote:
> Thanks, Sergey!

+1

This looks good then.

Thanks,
Vladimir K

>
> Best regards,
> Vladimir Ivanov
>
> On 11/20/14, 1:53 PM, Sergey Kuksenko wrote:
>> 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
>>