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.

if we change the way we do profiling so that we update shared counters less frequently, we can reduce the scaling problem. We can do this by randomization: we update shared counters less frequently, only when a random-number generator hits some value. While this introduces noise into the profile data, we can reduce memory contention to near zero.