One question about hotspot g1 heap adaptive resizing feature

[Thomas Schatzl]

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