Bug ID: JDK-8234863 Increase default value of MaxInlineLevel

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 11	JDK 14
11.0.10Fixed	14 b27Fixed

Several reports have been made that increasing MaxInlineLevel has a beneficial impact on real world applications.

Based on our set of performance benchmarks, there are no significant regressions from increasing MaxInlineLevel from the current default of 9 to 12-18, while renaissance see improvements on several benchmarks (up to 70% on scala kmeans), plateauing after 15.

I suggest we increase this value by default.

Fix Request (11u). Applies cleanly. Minimal compatibility risk (see the CSR). Minimal reliability risk, has been in production at Amazon since 11.0.7.
10-11-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/3c8af950e849 User: redestad Date: 2019-12-10 13:31:30 +0000
10-12-2019
[~neliasso]: Adding ways to tune C1 and C2 separately from each other sounds good, but also something that could (should?) be worked on independently of an adjustment to the default setting. Lacking evidence that an increase is likely to cause regressions, and with mounting evidence that a certain class of applications/benchmarks sees significant improvements, I'm going to move ahead with this proposal (file the CSR, run tests on the trivial code change, etc..).
04-12-2019
Don't forget that the MaxInlineLevel flag is shared with C1. I think we should separate them so that we can trim them seperatly, and reduce the risk of regressions.
27-11-2019
[~simonis]: Real data from real applications is of course needed to know for sure, but the evidence we have so far suggests the benefits are significant while potential downsides (longer/bigger compilations, more code cache use) have not manifested in our tests. In theory the maximum size of compilations is still bounded by a few other limits, such as MaxNodeLimit, but there is surely a risk that on average some specific application will see more large compilations. An open question is if this will have a noticeable effect. I've looked at code cache for a number of benchmarks, and differences are small and in the noise. Overall the effect on code cache is harder to predict, since more inlining possibly means more aggressive dead code elimination etc.
27-11-2019
What about memory consumption? Is there any evidence how much more native memory a compiler thread will use after such a change? And are there any effects on the code cache? I.e. will code cache usage go up because methods get bigger, down because fewer methods get compiled or does it basically stays the same?
27-11-2019
Yes, please. Are renaissance regressions (10-16%) on Windows just random?
26-11-2019

CSR :	JDK-8235336 - Increase default value of MaxInlineLevel
Relates :	JDK-8235673 - [C1, C2] Split inlining control flags