Request for Feedback and Testing on G1 Heap Resizing Prototype

[Thomas Schatzl]

Hi Ivan,

   thanks for working on this!

Some comments for people (Man, Monica, Kirk) potentially taking this for 
a spin:

On 29.04.25 12:46, Ivan Walulya wrote:
> As part of our preparations for AHS, we are prototyping changes to the 
> G1 heap resizing policy to improve the effectiveness of the GCTimeRatio 
> [1]. The GCTimeRatio is set to manage the balance between GC time and 
> Application execution time. G1's current implementation of GCTimeRatio 
> appears to have drifted from its intended purpose over time. It may no 
> longer accurately guide heap sizing in response to GC overhead. 
> Therefore, we need to change this mechanism with the goal that G1 better 
> manages heap sizes without the need for additional tuning knobs.
 > > The prototype allows both expansion and shrinking of the heap at 
the end
> of any GC, as opposed to the current behavior where shrinking is only 
> allowed at Remark or Full GC pauses [2].  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.

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.

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.
> Additionally, we are removing the heap resizing at the end of the Remark 
> pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. This 
> resizing of the heap ignores current application behaviour and may lead 
> to pathological cases of repeated concurrent mark cycles:
> 
>    *      we shrink the heap at remark,
>    *      a smaller heap triggers a concurrent marking in the subsequent
>     GCs as well as expanding the heap
>    *      the concurrent cycle ends in another remark pause where the
>     cycle restarts.
> 
> 
> We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at 
> the end of Full GC.

The use case for this might be ones similar to CraC to temporarily 
compact the heap as much as possible; however it might be better to have 
explicit control for that (e.g. a jcmd).

Ultimately there may be need to remove it as well for full gcs, 
replacing it with something else.
> As a result of these changes, applications may settle at more 
> appropriate and in some cases smaller heap sizes for a given 
> GCTimeRatio. While this may show as regression in some benchmarks that 
> are sensitive to heap size, it is still improved control over GC behaviour.
> 
> We are requesting for feedback or testing of these changes before 
> propose to merge them with mainline.
> 
> Some of the changes that are independent of the GCTimeRatio are already 
> out for review [4, 5], other minor fixes will be split out and pushed 
> independently.
> 
[0] https://github.com/openjdk/jdk/pull/24211

Hth,
   Thomas