One question about hotspot g1 heap adaptive resizing feature

[shaojun wang]

Hi Men Cao

I read one paper which its link is here: https://dl.acm.org/doi/epdf/10.1145/3617651.3622988, it adopts GC_CPU_time / App_CPU_time as the
key standard to resize ZGC's heap. While in jdk26 G1 adopts GC CPU overhead approach: GC_CPU_time / total_CPU_time.

In summary there are three kind of approches are:

  *
GCTimeRatio approach: GC_pause_time / total_wall_time
  *
GC CPU overhead approach_1: GC_CPU_time / total_CPU_time
  *
GC CPU overhead approach_2: GC_CPU_time / App_CPU_time

> For Shaojun's case, the application spends 42% of its wall time inside GC pauses. It's close to GC thrashing, so the JVM expands the heap to prevent that.
Does this behavior cause large heap size growth in JDK 26, compared to JDK 25? Could you provide a reproducer program or GC logs?
If the application has a small heap, https://bugs.openjdk.org/browse/JDK-8349978 is a known issue with the GCTimeRatio approach for small heaps.

I didn't encounter this issue, but just made a though experiment base on the assumption with GC CPU overhead approach_2.

Personally, I think GCTimeRatio approach is not very reasonable to G1 and ZGC, maybe it's good to PSGC.


From shaojun wang
ByteDance
________________________________
From: Man Cao <manc at google.com>
Sent: Monday, January 26, 2026 2:13 PM
To: hotspot-gc-dev at openjdk.org <hotspot-gc-dev at openjdk.org>
Cc: shaojun wang <jeffery.wsj at outlook.com>
Subject: Re: One question about hotspot g1 heap adaptive resizing feature

> 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?

The rationale for https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633 is that the GCTimeRatio approach is mostly based on pause times, instead of CPU time. The pause-time approach is more stable and less prone to drastic fluctuations. A simplified view for these two approaches is:
- GCTimeRatio approach: GC_pause_time / total_wall_time
- GC CPU overhead approach: GC_CPU_time / total_CPU_time

total_wall_time elapses at a constant rate, so it is a more stable denominator. I experimented with a synthetic workload that exhibits this problem using the GC CPU overhead approach. This problem did not appear with the GCTimeRatio approach.

For Shaojun's case, the application spends 42% of its wall time inside GC pauses. It's close to GC thrashing, so the JVM expands the heap to prevent that.
Does this behavior cause large heap size growth in JDK 26, compared to JDK 25? Could you provide a reproducer program or GC logs?
If the application has a small heap, https://bugs.openjdk.org/browse/JDK-8349978 is a known issue with the GCTimeRatio approach for small heaps.

Incidentally, we noticed some applications grow to a larger heap with JDK 26 compared to JDK 25. We have not yet examined this issue in depth.

-Man


On Mon, Jan 26, 2026 at 12:50 PM Man Cao <manc at google.com<mailto:manc at google.com>> wrote:
Since hotspot-gc-dev does not support pictures/screenshots, here is the context based on a previous email that Shaojun sent to me directly.

First screenshot is from https://github.com/openjdk/jdk/pull/24211#issuecomment-2777769994:

> Somewhat related to above, our experience with our internal algorithm that adjusts SoftMaxHeapSize based on GC CPU overhead, encountered cases that it behaves poorly. The problem is that some workload have large variance in mutator's CPU usage (e.g. peak hours vs off-peak hours), but smaller variance in GC CPU usage. Then it does not make much sense to maintain a constant % for GC CPU overhead, which could cause excessive heap expansion when mutator CPU usage is low. The workaround is to take live size into consideration when calculating SoftMaxHeapSize, which is similar to how Min/MaxHeapFreeRatio works.
> I'm not sure if GCTimeRatio using wall time and pause time could run into similar issues. I'm happy to experiment when we make progress on JDK-8238687/JDK-8248324/JDK-8349978.

Second screenshot is from https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633:

> Regarding to the fluctuating mutator CPU usage issue, upon reviewing https://github.com/openjdk/jdk/pull/26351, I'm 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.

-Man


On Fri, Jan 23, 2026 at 11:28 PM shaojun wang <jeffery.wsj at outlook.com<mailto:jeffery.wsj at outlook.com>> 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://bugs.openjdk.org/browse/JDK-8359348

From shaojun wang
ByteDance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20260127/db0342e5/attachment-0001.htm>