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-09-30
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 :  
JDK-8353716 - G1: AHS work umbrella
Relates :  
JDK-8352765 - G1CollectedHeap::expand_and_allocate() may fail to allocate even after heap expansion succeeds
Relates :  
JDK-8359211 - Automatic Heap Sizing for G1
Relates :  
JDK-8222145 - Add -XX:SoftMaxHeapSize flag
Relates :  
JDK-8349978 - G1: Retune G1 GCTimeRatio boosting during heap expansion for small heaps
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/27524 Date: 2025-09-26 11:45:52 +0000
30-09-2025
Min/MaxHeapFreeRatio observance has been de-facto removed from G1 with latest heuristics to better follow GCTimeRatio. It is only used for full gc and periodic gcs at this time, but at least the latter will almost likely be removed with JDK-8213198 that is being worked on by [~mbeckwit] as G1/AHS needs to use it for regular GCs to control heap size in idle phases.
30-09-2025
SoftMaxHeapSize just affects the target heap size for scheduling concurrent marks. GCTimeRatio sets the target as well, so the result is basically MIN(SoftMaxHeapSize, GCTimeRatio-based-target). The PR is already online as draft (https://github.com/openjdk/jdk/pull/27524), I'm just looking into a test right now. We would appreciate if you can test whether it works as you expect.
30-09-2025
[~tschatzl] Thanks for bring this up. No objection in handing this over to you. Is there a high-level plan on how SoftMaxHeapSize would interact with GCTImeRatio? Similar to the "precedence" or "hardness" issue discussed in https://github.com/openjdk/jdk/pull/24211, does SoftMaxHeapSize directly affect heap resizing logic after a young or full GC? The TestSoftMaxHeapSize.java in https://github.com/openjdk/jdk/pull/24211 checks how full GC interacts with SoftMaxHeapSize, and requires SoftMaxHeapSize having higher precedence over Min/MaxHeapFreeRatio (they are still used in G1HeapSizingPolicy::full_collection_resize_amount()).
29-09-2025
[~manc]: Now that some of the prerequisites for this change have been committed (Min/MaxHeapFreeRatio removed during Remark), may I take over this change? May I also reuse the test you added to that last PR? Thanks.
26-09-2025
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