RFR: 8372701: Randomized profile counters [v5]

[Andrew Haley]

On Tue, 9 Dec 2025 17:09:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Please use [this link](https://github.com/openjdk/jdk/pull/28541/files?w=1) to view the files changed.
>> 
>> Profile counters scale very badly.
>> 
>> The overhead for profiled code isn't too bad with one thread, but as the thread count increases, things go wrong very quickly.
>> 
>> For example, here's a benchmark from the OpenJDK test suite, run at TieredLevel 3 with one thread, then three threads:
>> 
>> 
>> Benchmark (randomized) Mode Cnt Score Error Units
>> InterfaceCalls.test2ndInt5Types false avgt 4 27.468 ± 2.631 ns/op
>> InterfaceCalls.test2ndInt5Types false avgt 4 240.010 ± 6.329 ns/op
>> 
>> 
>> This slowdown is caused by high memory contention on the profile counters. Not only is this slow, but it can also lose profile counts.
>> 
>> This patch is for C1 only. It'd be easy to randomize C1 counters as well in another PR, if anyone thinks it's worth doing.
>> 
>> One other thing to note is that randomized profile counters degrade very badly with small decimation ratios. For example, using a ratio of 2 with `-XX:ProfileCaptureRatio=2` with a single thread results in
>> 
>> 
>> Benchmark                        (randomized)  Mode  Cnt   Score   Error  Units
>> InterfaceCalls.test2ndInt5Types         false  avgt    4  80.147 ± 9.991  ns/op
>> 
>> 
>> The problem is that the branch prediction rate drops away very badly, leading to many mispredictions. It only really makes sense to use higher decimation ratios, e.g. 64.
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits:
> 
>  - Merge from master branch
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
>  - Fix x86 lambda
>  - More
>  - Merge branch 'master' into JDK-8134940
>  - Merge branch 'master' into JDK-8134940
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
>  - whitespace
>  - AArch64
>  - Minimize deltas to master
>  - ... and 48 more: https://git.openjdk.org/jdk/compare/7da91533...96db42e2

> Yes. And I hope after #25305 you can really just specialize installation code a little: that code already knows whether it is about to install new receiver type in the table (so it can just write `1`), or it is an increment of known receiver (which can go RNG route). The poly counter would need some thinking about.

Sure, I'm excited to do that. Please merge as soon as you can. Do you intend to do the same for AArch64? I volunteer, if you like.

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

PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3657089677