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

[Vladimir Kozlov]

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.

Did you run all benchmarks in performance infrastructure for jdk9 
changes? There should be no regression.

thanks,
Vladimir

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