RFR: 8372701: Randomized profile counters [v5]

[Oli Gillespie]

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

I tested the jython benchmark on my x86 host and while I didn't see the reported >10% regression, I did see some differences. Profiling hinted at String operations, and playing with jdk String benchmarks I found that enabling randomized profile counters seems to make the performance of `micro:org.openjdk.bench.java.lang.StringIndexOfChar.latin1_SSE4_String` bi-modal on my setup. See results at https://gist.github.com/olivergillespie/33324b5e95e1d8fc64dbcbff1884dade. I don't know how or if that connects to the other curious results, but sharing just in case it's helpful. Can provide any details/perfasm etc. if needed.

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

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