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

[Vladimir Ivanov]

Thanks, Sergey!

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
>