Details
-
Enhancement
-
Resolution: Fixed
-
P4
-
8-shenandoah, 11-shenandoah, 14, 15
-
b18
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8245351 | 14u-cpu | Aleksey Shipilev | P4 | Resolved | Fixed | master |
JDK-8244357 | 14.0.2 | Aleksey Shipilev | P4 | Resolved | Fixed | b05 |
Description
ShenandoahGarbageThreshold drives the collection set selection. It defaults to 60%, which means we can end up with regions that have 60% garbage that would not be collected until the memory is tight. This means that Shenandoah accepts 60% heap fragmentation in normal conditions: so, for the live data of 20GB, it might require the heap of 33GB.
Instead, we are better off defragmenting the heap more proactively by lowering the ShenandoahGarbageThreshold.
Instead, we are better off defragmenting the heap more proactively by lowering the ShenandoahGarbageThreshold.
Attachments
Issue Links
- backported by
-
JDK-8244357 Shenandoah: tune down ShenandoahGarbageThreshold
- Resolved
-
JDK-8245351 Shenandoah: tune down ShenandoahGarbageThreshold
- Resolved