RFR: 8350852: Implement JMH benchmark for sparse CodeCache

[Evgeny Astigeevich]

On Thu, 6 Mar 2025 19:01:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Hmm, I am wondering what effect you are measuring. You executing methods sequentially. Is it possible the effects you see is CodeCache pages loading. The more groups you have, the more space they take in CodeCache.

I don't know what's happening on Intel. It's an open question. Maybe someone from Intel might explain regressions. Or I'll try to figure out it later.

On Neoverse: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/neoverse-v1-platform-a-new-performance-tier-for-arm:

> **Front-end – Branch prediction and stalls**
>
> Another significant change is doubling the number of concurrent code regions tracked in the front-end of the design which results in a large speedup for Java-type workloads with sparse code regions. Net result of all these improvements is up to 90% reduction in branch mis-predicts (for BTB misses) and up to 50% reduction in front-end stalls for common server/HPC workloads, compared to Neoverse N1 CPU.

You can see Neoverse front-end is limited to how many code regions it can handle without stalls. Don't mix up with OS pages.

I measure an effect of code being in many different regions. 
When all nmethods are in the minimum number of code regions. Calls of them have no penalties.
As soon as we spread nmethods among many code regions, code becomes sparse and we start getting stalls.

> Is it possible the effects you see is CodeCache pages loading. The more groups you have, the more space they take in CodeCache.

Yes, the percent of iTLB-load-misses increased but it's low: changed from 0.5% to 0.6%. The main issue is too many code regions.

> May be it can be achieved by adding blobs of different sizes between nmethods. You already use blobs to align group's start address.

This will only make code more sparse.

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

PR Comment: https://git.openjdk.org/jdk/pull/23831#issuecomment-2705085399
PR Comment: https://git.openjdk.org/jdk/pull/23831#issuecomment-2705088419