RFR: 8254913: Increase InlineSmallCode default from 2000 to 2500 for x64

[Claes Redestad]

On Mon, 19 Oct 2020 06:43:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have seen some specific benefits to increasing InlineSmallCode to 2500 from 2000, and across the whole promo build
>> perf test collection the change is neutral to slightly positive, where the tests are run on modern OCI systems.
>> Passed tier1 testing, some ad-hoc perf testing and more compiler related parts of the weekly promo performance set.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8254913
>> Thanks,
>> Eric
>
> Changing the global inlining defaults without providing the justifying performance data is not acceptable. @cl4es,
> please rescind your review if you can, so that change is not integrated by accident.

What constitutes a full promotion is proprietary, but I can verify no regressions across at least:

- SPECjvm2008*
- SPECjbb2005
- SPECjbb2015**
- Dacapo
- Renaissance

Notable improvements on Renaissance-DecTree (6%), Renaissance-Reactors (5%), Dacapo-lusearch (2%)
Various micros in the OpenJDK corpus improve significantly, e.g., AES_ECB_NoPadding 10% ChaCha20Poly1305 7%. No
detected regressions.

I agree that some more info about code cache utilization across a more complete range of workloads is a reasonable
request, but we've detected no regressions in our sample of footprint tests. I'm sure @ericcaspole won't integrate this
without first coming back with more data on this.

* not running the broken compiler sub-benchmarks
** interestingly most SPECjbb2015 publications in recent years have included -XX:InlineSmallCode=10k or more, see
   https://www.spec.org/jbb2015/results/

-------------

PR: https://git.openjdk.java.net/jdk/pull/705