On Thu, 13 Aug 2026 16:36:27 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 with a new target base due to a > merge or a rebase. The pull request now contains 201 commits: > > - Fix RISC V > - Fix RISCV > - Fix merge > - Fix RISCV > - Fix Arm-32 after merge. > - Merge branch 'JDK-8134940' of https://github.com/theRealAph/jdk into > JDK-8134940 > - Merge branch 'master' into JDK-8134940 > - _c1_needs_stack_repair is useless and should be removed > - Tidy remove_frame() > - Fix conflict > - ... and 191 more: https://git.openjdk.org/jdk/compare/b1467bd6...5119f86c > I think this speaks to the _hypothesis_ I had in my first comment here: > [#28541 > (comment)](https://github.com/openjdk/jdk/pull/28541#issuecomment-3586901495): > a randomized profile, even at lower PCRs, is distorted enough to cause > significant recompilation churn due to subsampling 1->0 updates that would > yield about-to-be-hit uncommon traps in C2 generated code. We are hitting 3x > (!) more uncommon traps on mid-level PCRs; I suspect that is why warmup is > that much worse. But that comment is about type profiles, and we never subsample 0->1 updates, regardless of capture ratio. We first look at whether a type has been seen at all, even only once, and only if it has do we subsample. > With high-level PCRs, from the look at compilation times, we seem to just > linger in profiling code much longer, never getting to tier4, so warmup is > worse again. That seems to speak against the idea that we have enough > profiling traffic updates to level out the "stepped" increases in counters. There could still be a real bug in that area; the arithmetic is fiddly. There's no reason (in theory) why tier 3->4 compilation should be delayed, absent a really high PCR. > So the more I look into performance model of this approach, the weirder and > weirder feelings I feel. I get that ultimately it might come to selecting the > good PCR for the concrete workload. But I struggle to find a workload yet > where "good PCR" even exists... Something is off somewhere. It sounds like it is. I'll have a look at the causes of the uncommon traps. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-5372513388
