RFC: AArch64: Set Segmented CodeCache default size to 127M

[Andrew Haley]

On 2/10/22 23:02, Astigeevich, Evgeny wrote:
> We’d like to discuss a proposal for setting TieredCompilation Segmented CodeCache default size to 127M on AArch64 (https://bugs.openjdk.java.net/browse/JDK-8280150).

I don't think so, at least not without a lot more information.

This would halve the size of the code cache, potentially causing
severe regressions in production. I have seen bug reports from
customers mystified at poor OpenJDK performance which have turned out
to be code cache thrashing. This is very hard to diagnose without
making some inspired guesses at what the root cause may be. We'd be
moving the threshold for cache exhaustion much closer to our default
configuration.

So, this is a trade off between a small expected gain and a much
larger (but hopefully rare) loss.

I'd like to see more information. What was the *average performance
gain* of all your benchmarks? I don't think anyone is interested in
cherry-picked best cases.

A quick back-of-the-envelope calculation tells me that about 3.5% of
the code cache is occupied by trampolines and the extra bytes used by
far calls. However, many of the far calls are never needed; I don't
have stats for that, but I'd guess about half of them. But given the
(plausible ?)  assumption that the dynamic frequency of calls is the
same as the static frequency, I wouldn't be surprised if the cost of
trampoline calls is about 2% of the total instruction count, so it'd
be nice to be rid of them if there were no cost; but there is a cost.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671