One question about hotspot g1 heap adaptive resizing feature

[Man Cao]

> 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> 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>
> 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: 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: 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/20260126/c84dab26/attachment-0001.htm>