-
Bug
-
Resolution: Unresolved
-
P4
-
15
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 ofJDK-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.
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
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.
- is blocked by
-
JDK-8248322 G1: Refactor full collection sizing code
- Resolved
- relates to
-
JDK-8238687 Investigate memory uncommit during young collections in G1
- Open
-
JDK-8248324 G1: Remove resizing during Remark
- Open
-
JDK-6490394 G1: Allow heap shrinking / memory unmapping after reclaiming regions during Remark
- Resolved