Moving Forward with AHS for G1

[Monica Beckwith]

Hi Ivan,
Thanks for the note — and nice to meet you!

The refinements you're working on around GCTimeRatio and memory uncommit are valuable contributions to the broader AHS direction we've been shaping. They align closely with the multi-input heap sizing model Thomas and I outlined — especially the emphasis on GC cost (via GCTimeRatio) and memory responsiveness as primary drivers.

These kinds of enhancements are central to making G1’s heap sizing more adaptive and responsive, particularly in environments with shifting workload patterns. I’m especially interested in your work around improving the GC time-base — it seems like a crucial piece for coordinating GC-triggered adjustments more precisely.

Given the growing collaboration across contributors, I’ve been thinking of opening an umbrella issue to track these efforts and possibly drafting a JEP to help clarify and unify the overall scope. With Oracle, Google, and others actively contributing, it’s exciting to see a shared vision taking shape — and your work is clearly part of it.

I’m genuinely excited to see this come together. Looking forward to continuing the discussion and shaping the future of G1 ergonomics together.

Best,
Monica

[cid:989053f7-0fb6-4f61-b4fe-cc68816546af]<https://outlook.office.com/bookwithme/user/6dc2f1f46dfd446aa456d1c1245cecd6@microsoft.com?anonymous&ep=bwmEmailSignature>
Book time to meet with me<https://outlook.office.com/bookwithme/user/6dc2f1f46dfd446aa456d1c1245cecd6@microsoft.com?anonymous&ep=bwmEmailSignature>

________________________________
From: Ivan Walulya <ivan.walulya at oracle.com>
Sent: Monday, March 24, 2025 6:43 AM
To: Monica Beckwith <Monica.Beckwith at microsoft.com>
Cc: Thomas Schatzl <thomas.schatzl at oracle.com>; hotspot-gc-dev at openjdk.org <hotspot-gc-dev at openjdk.org>
Subject: [EXTERNAL] Re: Moving Forward with AHS for G1

Hi,

Thanks for the summary.

At Oracle, we are refining the use of GCTimeRatio and enhancing the memory uncommit mechanism [3]. Specifically, we are exploring uncommitting memory during any GC event, rather than restricting it to Remark or Full GCs, as in the current implementation. Additionally, we are investigating ways to improve on the current use of GC events as a time-base.

// Ivan

On 21 Mar 2025, at 01:19, Monica Beckwith <monica.beckwith at microsoft.com> wrote:

Hi all,

Following up on the previous discussions around Automatic Heap Sizing (AHS) for G1, I wanted to summarize the key takeaways and outline the next steps.

In my November message [1], I described how AHS could dynamically manage heap sizing based on multiple inputs, including global memory pressure, GCTimeRatio policy, and user-defined heap tunables. This aligns with Thomas’s summary [2], which outlines how AHS integrates with G1’s existing mechanisms, including CPU-based heap resizing (JDK-8238687) [3], external constraints like CurrentMaxHeapSize (JDK-8204088) [4], and SoftMaxHeapSize (JDK-8236073) [5] as a key influence on heap adjustments.

AHS will operate as a broader mechanism, where SoftMaxHeapSize serves as a heuristic to guide memory management but does not impose strict limits. It will work in conjunction with CPU-based heuristics to manage heap growth and contraction efficiently.

Google’s previous work on ProposedHeapSize for G1 contributed valuable insights into adaptive heap management, but as discussions evolved, the consensus has shifted toward a model centered onSoftMaxHeapSize as a guiding input within AHS.

Given this consensus, I will proceed with the implementation of JDK-8236073 [5] to ensure that AHS integrates effectively with G1’s dynamic heap sizing policies.

I will share updates as the work progresses. If there are any additional concerns or areas where further clarification is needed, please let me know.

Thanks again for the valuable discussions.

Best,
Monica
________________________________
References
[1] Monica Beckwith, "Clarifications on AHS behavior and its role in G1," OpenJDK hotspot-gc-dev mailing list, November 2024. [<https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050191.html>https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050191.html]<https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/XXXXXX.html]>
[2] Thomas Schatzl, "Giving a rough summary about the system envisioned for G1," OpenJDK hotspot-gc-dev mailing list, February 2025. [https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-February/051069.html]
[3] OpenJDK Issue, "JDK-8238687: Improve CPU-based heap sizing in G1," OpenJDK Bug Database. [https://bugs.openjdk.org/browse/JDK-8238687]
[4] OpenJDK Issue, "JDK-8204088: Introduce CurrentMaxHeapSize to allow external heap constraints," OpenJDK Bug Database. [https://bugs.openjdk.org/browse/JDK-8204088]
[5] OpenJDK Issue, "JDK-8236073: Introduce SoftMaxHeapSize as a guide for G1 AHS," OpenJDK Bug Database. [https://bugs.openjdk.org/browse/JDK-8236073]


<Outlook-oy3qsdus.png><https://outlook.office.com/bookwithme/user/6dc2f1f46dfd446aa456d1c1245cecd6@microsoft.com?anonymous&ep=bwmEmailSignature>
Book time to meet with me<https://outlook.office.com/bookwithme/user/6dc2f1f46dfd446aa456d1c1245cecd6@microsoft.com?anonymous&ep=bwmEmailSignature>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250326/2bb26874/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-ycaceqlr.png
Type: image/png
Size: 528 bytes
Desc: Outlook-ycaceqlr.png
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250326/2bb26874/Outlook-ycaceqlr-0001.png>