On Fri, 21 Aug 2026 21:09:20 GMT, Aleksey Shipilev <[email protected]> wrote:
>>> I think this speaks to the _hypothesis_ I had in my first comment here: >>> [#28541 >>> (comment)](https://github.com/openjdk/jdk/pull/28541#issuecomment-3586901495): >>> a randomized profile, even at lower PCRs, is distorted enough to cause >>> significant recompilation churn due to subsampling 1->0 updates that would >>> yield about-to-be-hit uncommon traps in C2 generated code. We are hitting >>> 3x (!) more uncommon traps on mid-level PCRs; I suspect that is why warmup >>> is that much worse. >> >> But that comment is about type profiles, and we never subsample 0->1 >> updates, regardless of capture ratio. We first look at whether a type has >> been seen at all, even only once, and only if it has do we subsample. >> >>> With high-level PCRs, from the look at compilation times, we seem to just >>> linger in profiling code much longer, never getting to tier4, so warmup is >>> worse again. That seems to speak against the idea that we have enough >>> profiling traffic updates to level out the "stepped" increases in counters. >> >> There could still be a real bug in that area; the arithmetic is fiddly. >> There's no reason (in theory) why tier 3->4 compilation should be delayed, >> absent a really high PCR. >> >>> So the more I look into performance model of this approach, the weirder and >>> weirder feelings I feel. I get that ultimately it might come to selecting >>> the good PCR for the concrete workload. But I struggle to find a workload >>> yet where "good PCR" even exists... Something is off somewhere. >> >> It sounds like it is. I'll have a look at the causes of the uncommon traps. > >>> We are hitting 3x (!) more uncommon traps on mid-level PCRs; I suspect that >>> is why warmup is that much worse. >> >> But that comment is about type profiles, and we never subsample 0->1 >> updates, regardless of capture ratio. We first look at whether a type has >> been seen at all, even only once, and only if it has do we subsample. > > Yeah, but thinking that uncommon traps are maybe about cold branches, the > branch data that lost 0->1 update due to subsampling looks to be a plausible > way to get extra uncommon trap? Something along those lines... > Question for @shipilev : is Renaissance dotty an outlier, or is it typical? I have not checked, just picked a workload that I knew is JIT-sensitive. After the issue showed up prominently on it, I stopped looking further. I can take a broader look, if you want, but what happens on Dotty is enough of a red flag for me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28541#issuecomment-5526470143
