JDK-8236073 : G1: Use SoftMaxHeapSize to guide GC heuristics
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 15
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-12-17
  • Updated: 2025-04-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
Relates :  
Relates :  
Relates :  
Description
This issue tracks the integration of `SoftMaxHeapSize` as a guiding input for heap sizing and marking heuristics in G1.

It includes:
- Introduction of soft_max_capacity() in G1CollectedHeap
- Wiring into heap resizing policy and IHOP logic
- Maintaining compatibility with MinHeapSize and other GC tunables

This work is based on Thomas Schatzl's original patch and follow-up contributions by Man Cao (Google). The `SoftMaxHeapSize` flag provides a soft limit for committed heap memory, which G1 GC will attempt to stay below, when possible, without treating it as a hard cap.

Broader work related to a dynamic, multi-input AHS (Automatic Heap Sizing) mechanism — including responsiveness to external memory pressure, GCTimeRatio adaptation, and environmental constraints — is being tracked separately.

See also:
- [mailing list discussion: November 2024 summary] (https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050214.html)
- [mailing list: March 2025 update] (https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-March/051619.html)
- [PR: Initial integration of SoftMaxHeapSize](https://github.com/openjdk/jdk/pull/24211)
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24211 Date: 2025-03-24 23:07:08 +0000
24-03-2025

Tried to reformat the original patch (html file) to be readable as text file; isn't going to apply directly as some formatting has been lost, but the change is simple enough (and due to code changes would not apply directly anyway).
11-09-2024

FWIW, for ZGC you can set SoftMaxHeapSize below -Xms. The GC will try to keep the heap size below SoftMaxHeapSize, but it won't uncommit memory past -Xms. Some extra info about this that was thought about when SoftMaxHeapSize was introduced for ZGC: In HotSpot, -Xms denotes both the minimum heap size but also initial heap size. The minimum heap size is "the minimum committed memory for the heap", and the initial heap size is "the initially committed memory for the heap when the GC starts". There used to be a cumbersome way to set these two properties to different values. I "recently" created a new flag, MinHeapSize, so that the users could more easily set them. See JDK-8223837. We now flags with this relationship: MinHeapSize <= InitialHeapSize <= MaxHeapSize Now that SoftMaxHeapSize is manageable we can end up in a situation similar to what you are talking about: The user has set -Xmx == -Xms, but later decides that it might be good to shrink the heap. If SoftMaxHeapSize is set to a lower value, the GC will try to stay below that heap useage, but it won't uncommit the unused overhead. As a way to deal with that I created a prototype to make MinHeapSize manageable, see: JDK-8224879.
11-09-2020

Is it supported to set SoftMaxHeapSize below Xms? I hope it is supported, because it can help a process with Xms=Xmx to temporarily lower its footprint.
11-09-2020

Since a "hard" SoftMaxHeapSize may be followed by higher gc time, consider making the relevant options manageable so that a user can allow more gc usage during the time SoftMaxHeapSize is set lower to avoid unexpected expansions. I.e. giving the user the flexibility to opt for lower memory usage at higher GC activity.
07-02-2020