Request for Feedback and Testing on G1 Heap Resizing Prototype

[Thomas Schatzl]

Hi Man,

On 01.05.25 09:07, Man Cao wrote:
> Great progress! Thank you, Ivan. Optimistically, many of these changes 
> could make it to JDK 25.
> 
> I'm happy to do some experiments and provide feedback. Does [1] contain 
> all necessary changes?

Afaik yes.

> Will that branch be updated as parts of it merge 
> into master?

Ivan can answer that.

> 
> Some early questions/feedback below.
> 
>  > We also increase the default GCTimeRatio from 12 to 24 [3] (we are 
>  > choosing 24 but open to suggestions). The existing default causes the 
>  > heap to shrink too aggressively under the new policy in order to 
>  > maintain the target GCTimeRatio. A higher default provides a better 
> > balance and avoids shrinking heap.
 >> This changes the pause overhead target from ~8% (1/13) to 4% (1/25).
> Would it make G1 expand the heap more aggressively after incremental 
> collections compared to existing behavior? Could you share some early/ 
> rough performance numbers about 12 vs 24 with the prototype, such as 
> actual heap sizes, throughput differences?

That value has been found to create roughly same heap sizes at around 
the same performance +/- 1-2% throughput across our set of benchmarks 
that run out-of-box (iirc).

Again, Ivan may chime in here. Part of this request for feedback is 
about getting a larger coverage on this aspect.

(The increase in GCTimeRatio has actually been something that is long 
overdue regardless of this change, since G1's overhead decreased a lot 
in recent years.)

[...]
> Re Thomas's comments:
> 
>  > So if one were to make GCTimeRatio manageable (just for testing
>  > purposes), and made it a float (for better control), changes to it
>  > should reflect on the used heap size in the next few GCs automatically.
> 
> Making GCTimeRatio manageable sounds like a good idea. Do we plan to do 
> this eventually (why "just for testing purposes")?
> 
It's just not implemented in that branch :) Currently we think that 
GCTimeRatio will eventually get manageable and likely using floats as 
the integers are too coarse as divisors as the . Probably as a follow-up.

There is still the question whether to deprecate it in favor of some 
GCCPUUsagePercent or whatever it is going to be called to have more 
direct control.

>  > A SoftMaxHeapSize implementation based on the discussion in the PR [0]
>  > that only guides IHOP with changes in
>  > G1AdaptiveIHOPControl::actual_target_threshold() should be effective
>  > now, but there may be issues with this GCTimeRatio based heap sizing
>  > that would be interesting to explore.
> 
> If G1 strives to respect GCTimeRatio as the prototype proposes, our 
> existing use cases probably no longer need to set SoftMaxHeapSize (and 
> maintains a separate algorithm to calculate values for SoftMaxHeapSize).

The purpose of this request is also to understand whether 
SoftMaxHeapSize is still necessary :)

Sizing based on cpu usage may be more inconvenient and less exact at 
reducing to a particular target heap size (without OOME'ing) than a 
direct target heap size. (i.e. I can imagine the case where while the 
threshold is kind of a continuum, for a collector small changes to heap 
sizes can lead to radical changes in CPU usage, so G1 might flap back 
and forth all the time).

We also do not have real use cases with real applications where we would 
temporarily want to keep the heap below a certain value like we think 
you suggested.

Ignoring CraC like use cases where specific functionality would serve 
that use case better, one current use of SoftMaxHeapSize here is for 
tuning ZGC performance (since SoftMaxHeapSize is only implemented 
there), but we do not have seen uses for G1 (obviously as it's not 
implemented there, and one can use G1ReservePercent to some degree).

Note that G1 already has this G1ReservePercent that somewhat already 
acts like that, so there is a certain overlap that might need some 
resolving (and its default is too high for large heaps anyway). Or just 
changed to be adaptive.

SoftMaxHeapSize may also be necessary in some cases where there is more 
information available from the outside than AHS can ever know.

So it can be worthwhile experimenting with SMHS anyway.

I will update that umbrella CR with new thoughts in the next few days.

Thanks,
   Thomas