JDK-8238686 : G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 15
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-02-07
  • Updated: 2024-11-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.
JDK 25
25Unresolved
Related Reports
Blocks :  
JDK-8248322 - G1: Refactor full collection sizing code
Relates :  
JDK-8238687 - Investigate memory uncommit during young collections in G1
Relates :  
JDK-6490394 - G1: Allow heap shrinking / memory unmapping after reclaiming regions during Remark
Relates :  
JDK-8248324 - G1: Remove resizing during Remark
Description
Given a MMU specification (GCTimeRatio/MaxGCPauseMillis/GCPauseIntervalMillis) G1 has a particular "optimal" heap size goal to keep.

During Remark (and during full gc) we resize the heap according to Min/MaxHeapFreeRatio regardless of that heap size goal (= S_goal).

Given that at Remark G1 heap usage (S_remark) is almost peaked, with the default value of MinHeapFreeRatio of 40% G1 might expand much more or shrink much less than expected. I.e.

(1 + MinHeapFreeRatio) * S_remark >> S_goal

The difference between S_remark and S_goal will with high probability never be used, hence wasted for use by other processes.

This behavior may also lead to unexpected expansion of the heap, see the comment at the end of JDK-6490394.

The same applies to MaxHeapFreeRatio when deciding to shrink. There may be a huge amount of free regions after a one-time expansion but the goal heap size smaller than that. This is particularly noticeable on large heaps where the absolute amount of free unused space can be very large.

One sub-goal of this change may be removing the use of Min/MaxHeapFreeRatio for G1.
Comments
Looking at this is part of the currently ongoing AHS effort for G1. It is unlikely this will be changed until FC, so moving it to 25.
07-11-2024
An option would be to inhibit expanding the heap at Remark due to MinHeapFreeRatio and let regular collections like in JDK-8238687 do the expansion.
19-05-2020