RFR: 8372701: Randomized profile counters [v2]
Andrew Haley
aph at openjdk.org
Thu Nov 27 17:22:51 UTC 2025
On Thu, 27 Nov 2025 17:18:35 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.
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits:
>
> - Merge remote-tracking branch 'refs/remotes/origin/JDK-8134940' into JDK-8134940
> - whitespace
> - AArch64
> - Minimize deltas to master
> - Better
> - Inter
> - Cleanup
> - Cleanup
> - Merge master
> - D'oh
> - ... and 42 more: https://git.openjdk.org/jdk/compare/b2f97131...49d52d82
> Impressive work.
>
> Clashes a bit with #25305, which commons the type profile check and makes it more robust. It would be trivial to resolve, as _that_ PR has only one place where counter is updated. Also gives you some additional budget to spare for more instructions in profiled code. So it would be nice if that PR (and probably its AArch64 version) lands first.
Thanks.
Sure, it can wait for that PR.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3586849348
More information about the hotspot-dev
mailing list