JDK-8238687 : Investigate memory uncommit during young collections in G1
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-02-07
  • Updated: 2025-07-22
  • Resolved: 2025-07-09
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.
JDK 26
26 b06Fixed
Related Reports
Blocks :  
JDK-8353716 - G1: AHS work umbrella
Blocks :  
JDK-8357445 - G1: Time-Based Heap Uncommit During Idle Periods
Blocks :  
JDK-8248324 - G1: Remove resizing during Remark
Blocks :  
JDK-8244603 - G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
Blocks :  
JDK-8243672 - Short term pause time ratio calculation in G1 off
Blocks :  
JDK-8247843 - Reconsider G1 default GCTimeRatio value
Causes :  
JDK-8363884 - Regressions 6-11% on several G1 bmks after 8238687
Relates :  
JDK-8238686 - G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc
Relates :  
JDK-8349978 - G1: Retune G1 GCTimeRatio boosting during heap expansion for small heaps
Relates :  
JDK-8349939 - G1: Configurable heap expansion aggressiveness
Description
Currently G1 uncommits memory in the Remark pause only. It may be better to uncommit at other places (see JDK-8238686) when heap usage is actually low.

Similar to expansion, G1 could regularly check whether the GCTimeRatio is low enough (e.g. < 1/2 GCTimeRatio) to warrant heap shrinking.

Note that the amount of uncommit should be so that heap resizing activity during further operation is minimal.
Comments
Changeset: 47614796 Branch: master Author: Ivan Walulya <iwalulya@openjdk.org> Date: 2025-07-09 05:44:42 +0000 URL: https://git.openjdk.org/jdk/commit/4761479608d5a8ecc504e343109900b0d0c77171
09-07-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25832 Date: 2025-06-16 14:05:52 +0000
16-06-2025
The reason why this investigative CR suggests to (also) uncommit at any gc, is that the current places where resizing is can be extremely rare (marking) to not existent during application execution. See e.g. the use case in JDK-8349939 where additional measures are taken to guarantee regular marking to expedite uncommit.
13-02-2025
Another option to decrease the heap over time more aggressively could be adopting a scheme more similar to ZGC: track unused pages and after x time it has not been used, uncommit it. Another probably better option to track gctimeratio would be regular tracking in the service thread to decrease heap not only at GCs (which can be spaced apart arbitrarily).
13-02-2025
Before we can fix this, gc time ratio tracking must be fairly correct, i.e. properly track actual gc time ratio (JDK-8243672) and try to avoid unnecessary gc time ratio spikes (JDK-8244603)
15-05-2020