> 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. > > 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.
Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28541/files - new: https://git.openjdk.org/jdk/pull/28541/files/7d124fd2..a1ed4b80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28541&range=05-06 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28541.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28541/head:pull/28541 PR: https://git.openjdk.org/jdk/pull/28541
