One question about hotspot g1 heap adaptive resizing feature

[Thomas Schatzl]

Hi Erik,

On 28.01.26 13:41, Erik Osterlund wrote:
> Hi Thomas,
> 
> If I understand the conversation, what is referred to is something like 
> this in ZGC style AHS:
> https://github.com/openjdk/zgc/blob/ 
> c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/ 
> zAdaptiveHeap.cpp#L505 <https://github.com/openjdk/zgc/blob/ 
> c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/ 
> zAdaptiveHeap.cpp#L505>
> 
> and:
> https://github.com/openjdk/zgc/blob/ 
> c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/ 
> zAdaptiveHeap.cpp#L515 <https://github.com/openjdk/zgc/blob/ 
> c87666fbda432c9c9d19d6871859b8c195476f6c/src/hotspot/share/gc/z/ 
> zAdaptiveHeap.cpp#L515>
> 
> The reasoning here is that if you have a process that utilizes 1% of the 
> machine CPU resources but 50% of the memory resources, you might not 
> want to bloat memory with lots of garbage to reduce fraction of that 1% 
> that is spent of GC. In that situation, having a 100% CPU overhead so 
> that the JVM uses 2% of the overall machine CPU, while saving a huge 
> amount of the available RAM, is preferable. In other words, the CPU 
> overhead target depends on the resource balance of unused machine 
> resources, as well as a resource balance of the process used resources.
> > In terms of use cases, containers without resource constraints or
> partial resource constraints, is one application. Multi process 
> situations would be another one.

Thanks for highlighting this aspect. The mentioned use case does not 
seem to consider multi-process situations, but I filed 
https://bugs.openjdk.org/browse/JDK-8376662 for G1 to remember.

It is also interesting to see that apparently containers can access 
global state like total machine cpu usage.

As far as I understood, the original use case was solely the concern 
that when the application is doing "nothing", the existing gctimeratio 
policy would somehow expand the heap because cpu activity would be high.

This somewhat seemed to be a contradiction to me.

Thinking about it a bit more, it is indeed possible in case the 
application did not actually allocate anything, but cause extreme gc 
activity due to reference updates / refinement, so at the next gc G1 
would expand unnecessarily. I filed 
https://bugs.openjdk.org/browse/JDK-8376663 to investigate this too.

Another possibility is that Shaojun is concerned because if the 
application really did "nothing", the heap is not _shrunk_ because there 
is no gc activity.

For that case, currently the user must enable periodic gcs manually in 
G1. In the future a form of it will by enabled by default (and needs to 
be disabled manually).

Thomas