One question about hotspot g1 heap adaptive resizing feature

[Erik Osterlund]

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

and:
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.

/Erik


On 27 Jan 2026, at 19:00, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:

Hi all,

On 24.01.26 08:28, shaojun wang wrote:
Hi Men Cao
I read one openjdk bug which discuss  G1 heap adaptive resizing feature, and I noticed that you mention one question like this:
image.png
and then you mentioned that you were convinced that the proposed approach does not suffer from this issue. This is because the proposed approach
does not rely on the total process CPU usage, and does not measure "GC CPU overhead", i.e., a ratio of GC CPU usage over total CPU usage.
image.png
my question is that even with GCTimeRatio(gc time / (gc time + app time)) , the problem will still exist if the application
fall into a very low cpu cost state. for example, gc_time = 30, app_time=40，GCTimeRatio is: 30/(30+40)= 0.42, the g1
heap size policy will try to extend heap size to scale down GCTimeRatio。But actually the application doesn't care about
its performance at all under the state，because there is basically no or merely request for the app. Do you have idea about
it?
https://github.com/openjdk/jdk/pull/24211 <https://github.com/openjdk/ jdk/pull/24211>
https://bugs.openjdk.org/browse/JDK-8359348 <https://bugs.openjdk.org/ browse/JDK-8359348>
 just to confirm your use case:

- The application is doing nothing ("because there is basically no or
merely [rarely?] request for [from?] the app.")

- _GC_ cpu usage is high.

The failure is that G1 would expand the heap due to the GCTimeRatio based heap sizing? Or keep heap size as is, at a probably too large value, compared to pre-GCTimeRatio sizing?

My request is to give an example where GC cpu usage is high and there is little application activity?

Considering "activity" as memory allocation activity, as GC only triggers lazily because of allocation.

Thanks,
 Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20260128/a6049ac1/attachment-0001.htm>