JDK-8238687 : Investigate memory uncommit during young collections in G1
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 15
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-02-07
  • Updated: 2025-05-27
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-8247843 - Reconsider G1 default GCTimeRatio value
Blocks :  
JDK-8353716 - G1: AHS work umbrella
Blocks :  
JDK-8357445 - G1: Time-based heap size re-evaluation
Blocks :  
JDK-8244603 - G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
Blocks :  
JDK-8248324 - G1: Remove resizing during Remark
Blocks :  
JDK-8243672 - Short term pause time ratio calculation in G1 off
Relates :  
JDK-8238686 - G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc
Relates :  
JDK-8349939 - G1: Configurable heap expansion aggressiveness
Relates :  
JDK-8349978 - G1: Reconsider G1 GCTimeRatio boosting during heap expansion for small heaps
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
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