One question about hotspot g1 heap adaptive resizing feature

[Man Cao]

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/293c8e4c/attachment.htm>