Request for Feedback and Testing on G1 Heap Resizing Prototype

[Man Cao]

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? Will that branch be updated as parts of it merge into
master?

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?

> 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:
In the new prototype, does the pathological case happen with the default
MinHeapFreeRatio=40 MaxHeapFreeRatio=70 value? Or mainly with smaller
user-defined values for MinHeapFreeRatio/MaxHeapFreeRatio?

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")?

> 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).
Our use case still needs CurrentMaxHeapSize, but it could be followed up in
https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-April/051996.html.

[1]
https://github.com/openjdk/jdk/compare/master...walulyai:jdk:G1HeapResizePolicy


-Man


On Tue, Apr 29, 2025 at 4:34 AM Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250501/d6184c3c/attachment-0001.htm>