RFR: 8326205: Grouping frequently called C2 nmethods in CodeCache [v6]

[Evgeny Astigeevich]

On Fri, 16 Jan 2026 11:24:08 GMT, George Wort <duke at openjdk.org> wrote:

>> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix builds
>
> Hi, 
> 
> I've played around with this PR a bit and had a few thoughts.
> 
> The way the grouping is set up currently means that if you run the program for long enough you will keep adding profiled code onto the hot code heap, even if it doesn't really meet the definition of hot. This also means that if the program changes "phase", and the hot code changes, the hot code heap might already be full and you will be unable to compact the new hot code. Have you thought about adding some kind of refresh/reset when the hot code heap is full, to purge code that has not appeared in recent profiles?
> 
> Other small configuration changes that helped me try this out, adding a delay variable to avoid profiling the setup period of a program, and making the sampling period configurable.

Hi @GeorgeWort 
Thank you for the feedback.

> The way the grouping is set up currently means that if you run the program for long enough you will keep adding profiled code onto the hot code heap, even if it doesn't really meet the definition of hot. This also means that if the program changes "phase", and the hot code changes, the hot code heap might already be full and you will be unable to compact the new hot code.

We've seen only cases when an application after running for long enough gets a stable profile which stays almost unchanged forever.
We currently rely on GC removing cold nmethods from HotCodeHeap. An application gradually switches between states of being idling and being active.

So, possible cases:
- Running <-> Idling. If no new nmethods appear, nothing should be removed from HotCodeHeap. If they appear, some other should become cold and be remove by GC. We will detect new nmethods and move them to HotCodeHeap.
- Running Profile 1 <-> Running Profile 2. If both profiles cannot be kept in HotCodeHeap, we will have a problem. We will depend on how quickly switching between profiles happens. Anyway switching between profiles might cause performance issues: throwing away nmethods from HotCodeHeap, interpreting them again, recompiling them, relocating them to HotCodeHeap.

>  Have you thought about adding some kind of refresh/reset when the hot code heap is full, to purge code that has not appeared in recent profiles?

We can consider relocating nmethods back to the normal heap, the non-profiled code heap.
IMO we should do this instead of GC throwing them away. If after being moved to the normal heap they become cold, GC will remove them from CodeCache. If they become hot again, they will be relocated to HotCodeHeap.

> 
> Other small configuration changes that helped me try this out, adding a delay variable to avoid profiling the setup period of a program, and making the sampling period configurable.

Yes, this is useful. We can consider adding it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27858#issuecomment-3770383465