On Fri, 10 Jul 2026 13:30:09 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 159 commits: > > - Review feedback > - Merge branch 'master' into JDK-8134940 > - Disable runtime check in PRODUCT mode. > - More > - new test > - More > - Whitespace > - More > - More > - Oops > - ... and 149 more: https://git.openjdk.org/jdk/compare/a230a609...1712be31 More findings... src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 575: > 573: __ verify_not_null_oop(exception_oop); > 574: > 575: __ restore_profile_rng(); I do not see the same in x86 and ARM versions of `Runtime1::generate_unwind_exception`? Should it also be there? src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 1385: > 1383: Register recv = k_RInfo; > 1384: __ load_klass(recv, obj, tmp_load_klass); > 1385: ce->type_profile_helper(mdo, md, data, recv, Rtmp1); So on this path, we have `type_profile_helper` -> `profile_receiver_type(&increment_mdo)` -> `step_random`. But there is `step_random` below as well. Does that mean we step *twice*? src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 2912: > 2910: > 2911: // If (dest & mask) < step, we just overflowed. > 2912: __ andl(dest, freq_opr->as_jint()); There is something fishy here, in interaction with the masks. If the mask is smaller than the step, would that mean we *always* mask out the bits, and therefore we *always* notify? It is a pesky issue, and I think we gotta cap the `ProfileCaptureRatio` with various `Tier*InvokeNotifyFreqLog`-s... src/hotspot/cpu/x86/globals_x86.hpp line 199: > 197: "Explicitly selected mechanism will fail at startup if " > \ > 198: "hardware does not support it.") > \ > 199: range(-1, 5) Don't drop the trailing `` here :) src/hotspot/share/compiler/compilationPolicy.cpp line 1380: > 1378: CompLevel CompilationPolicy::call_event(const methodHandle& method, > CompLevel cur_level, JavaThread* THREAD) { > 1379: CompLevel osr_level = MIN2((CompLevel) > method->highest_osr_comp_level(), common<LoopPredicate>(method, cur_level, > THREAD, true)); > 1380: CompLevel next_level = common<CallPredicate>(method, cur_level, > THREAD, !TrainingData::have_data() && is_old(method)); You accidentally undid [JDK-8386852](https://bugs.openjdk.org/browse/JDK-8386852). ------------- PR Review: https://git.openjdk.org/jdk/pull/28541#pullrequestreview-4684098606 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3570129992 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3570400791 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3570384695 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3570406170 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3570098624
