RFR: 8372701: Randomized profile counters [v2]
Aleksey Shipilev
shade at openjdk.org
Mon Dec 15 11:18:31 UTC 2025
On Mon, 15 Dec 2025 10:38:21 GMT, Andrew Haley <aph at openjdk.org> wrote:
> I've been thinking about this some more, and I wonder how important it really is. Let's say we don't compile a method until it's been interpreted a couple of hundred times (it's at least 128). We're speculating that the call site is polymorphic, but so far has been called only monomorpically, so we need to check every invocation, just in case. I guess this does happen occasionally during some application warmup scenarios, but does it really matter?
For steady state it does not matter. But for warmup, Leyden teaches us (we were whack-a-mole-ing problems like these for the better part of the year there) that misguided trap-recompilation trip through C2 costs a lot. The compiler dynamics gets so funky that you start looking out for things that look "probably fine" on paper, but may conspire against you every so often. This looks to me as one of those things.
To make matters worse, for the applications that have clearly defined warmup/steady states, there is code that would execute _only_ during warmup. Think initialization code that takes a particular path once and only once. For warmup in AOT mode, you really want that code to be generated ahead of time. Because it defeats the purpose of AOT to spend lots of JIT compilation time recompiling for a one-off initialization case. Which forces AOT code to be compiled more pessimistically. I can see how missing a rare receiver sets up AOT compilation for overly optimistic compilation that would trap at runtime, and at the worst time -- at warmup -- when compilers are already burning up.
In other words, that "does happen occasionally during some application warmup scenarios" is one of the things that Leyden tries to summarily avoid.
To your example: indeed, there is no recourse in case when really-polymorphic site is accidentally looking monomorphic due to code behavior artifacts: e.g. no one came with rare type just yet. But IMO that does not mean we would be opening more performance trap-doors when some code _did_ come with the rare type, especially if it is easy to handle.
The fact that some of your horses might have bolted, does not give you a good reason to open the barn door a bit wider :)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-3655073299
More information about the hotspot-dev
mailing list