On Tue, 14 Jul 2026 10:56:10 GMT, Andrew Haley <[email protected]> wrote:
>> Please use [this >> link](https://github.com/openjdk/jdk/pull/28541/changes?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. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Andrew Haley has updated the pull request incrementally with two additional > commits since the last revision: > > - Merge branch 'JDK-8134940' of https://github.com/theRealAph/jdk into > JDK-8134940 > - Simplify overflow handling Looks ok, modulo a few queries of my own and a small number of hanging comments from @shipilev. src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 2670: > 2668: > 2669: if (counter_stub != nullptr) { > 2670: __ ubfx(rscratch1, r_profile_rng, 28 - ratio_shift, ratio_shift); Why is this 28 - ratio_shift? src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp line 278: > 276: // In effect, the CRC instruction is being used here for its > 277: // linear feedback shift register. > 278: movl(temp, 0); On aarch64 we have asserts to detect a zero state when using crc32. Why do we not also need them here on x86? Likewise in the save and restore routines? ------------- PR Review: https://git.openjdk.org/jdk/pull/28541#pullrequestreview-4693412181 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3579498463 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3579993366
