On Fri, 5 Jun 2026 07:55:59 GMT, Aleksey Shipilev <[email protected]> wrote:
> What I am concerned about is the profile inversion. If there is a hot branch, > it would probably progress to C1 profiling, where it would be subsampled, and > would add up to profile only after some time. Some compilations will be delayed, and some will be advanced, with approximately equal probability. > But the _cold_ branch that is running in intepreter would show up in profile > right away. So there is time window where cold branch is over-represented > over hot branch in profile. Randomized profile counters add some noise to profile counts. The counters can trigger overflow earlier _or later_ than they would have done without randomization. I think the noise added to profile counters has something like a Poisson distribution, so on average the error is about √N, where N is the number of random samples. If you have a compilation threshold of 1024 it'll take on average 1024 sampling events to trigger compilation, regardless of `ProfileCaptureRatio`. Of those 1024 events, on average only 16 will actually increment the associated counter by 64. √16 = 4, so the number of counts when compilation is signalled is 1024, +- 256 for one standard distribution. > With large `ProfileCaptureRatio` this window can be uncomfortably large and > fairly close to triggering the compilation with skewed profile? > > It is not much of the problem with receiver type profiling, where interpreter > and C1 are on the same subsampling footing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28541#discussion_r3364412905
