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 Real close, audit finds mostly cosmetics. src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 1456: > 1454: = __ form_address(rscratch2, mdo, > 1455: md->byte_offset_of_slot(data, > DataLayout::flags_offset()), > 1456: LogBytesPerWord); Why `LogBytesPerWord`, and not `0` as in original? src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 1484: > 1482: type_profile_helper(mdo, md, data, recv, Rtmp1); > 1483: } else { > 1484: __ testptr(value, value); Seems to have already did the same thing at L1467. 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); Also `xorl(tmp, tmp)` or `xorptr(tmp,tmp)` this to save a few bytes :) src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 681: > 679: __ verify_not_null_oop(exception_oop); > 680: > 681: __ restore_profile_rng(); Cosmetics, misindented: Suggestion: __ restore_profile_rng(); src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 683: > 681: __ restore_profile_rng(); > 682: > 683: // get throwing pc (= return address). Cosmetics, put it back: Suggestion: // get throwing pc (= return address). src/hotspot/share/c1/c1_Compilation.cpp line 297: > 295: } > 296: > 297: // generate code for slow cases All of the hunks in this file are cosmetic, and you can make PR a bit smaller by not doing them :) ------------- PR Review: https://git.openjdk.org/jdk/pull/28541#pullrequestreview-4697020573 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3581338269 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3581328998 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3581353984 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3581348088 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3581317815 PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3581344676
