-
Bug
-
Resolution: Fixed
-
P3
-
12, 17, 21, 22
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8331845 | 21.0.4 | Liang Mao | P3 | Resolved | Fixed | b02 |
During the Remark pause we use the full gc heap resizing policy.
One important metric is the amount of free space/regions at that point; it is calculated as
const size_t used_after_gc = capacity_after_gc - _g1h->unused_committed_regions_in_bytes();
The problem with that formula is that at the point when the Remark pause occurs, Eden is not empty compared to full gc.
So the result of this calculation is very dependent on the point in time the Remark pause occurs, and so is the result whether g1 expands the heap or not. The suggestion is to incorporate current eden size as well.
Introduced inJDK-6490394.
This can cause lots of unnecessary heap expansions and heap usage.
One important metric is the amount of free space/regions at that point; it is calculated as
const size_t used_after_gc = capacity_after_gc - _g1h->unused_committed_regions_in_bytes();
The problem with that formula is that at the point when the Remark pause occurs, Eden is not empty compared to full gc.
So the result of this calculation is very dependent on the point in time the Remark pause occurs, and so is the result whether g1 expands the heap or not. The suggestion is to incorporate current eden size as well.
Introduced in
This can cause lots of unnecessary heap expansions and heap usage.
- backported by
-
JDK-8331845 G1: Heap resizing at Remark does not take existing eden regions into account
- Resolved
- relates to
-
JDK-8315866 Regression 3-4% on Renaissance Reactors on both Mac platforms
- Closed
-
JDK-6490394 G1: Allow heap shrinking / memory unmapping after reclaiming regions during Remark
- Resolved
- links to
-
Commit openjdk/jdk21u-dev/93d091ad
-
Commit openjdk/jdk/762b6529
-
Review openjdk/jdk21u-dev/429
-
Review openjdk/jdk/15400
(2 links to)