-
Enhancement
-
Resolution: Fixed
-
P3
-
8-shenandoah, 11-shenandoah, 14, 15
-
b01
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8250063 | 15.0.2 | Aleksey Shipilev | P3 | Resolved | Fixed | b01 |
JDK-8250361 | 15.0.1 | Aleksey Shipilev | P3 | Resolved | Fixed | b03 |
JDK-8247871 | 15 | Aleksey Shipilev | P3 | Resolved | Fixed | b29 |
JDK-8249110 | 14u-cpu | Aleksey Shipilev | P3 | Resolved | Fixed | master |
JDK-8248955 | 14.0.2 | Aleksey Shipilev | P3 | Resolved | Fixed | b12 |
Currently, every phase in normal cycle gets 1/3 (mark), 1/2 (evac) and 1 (update-refs) of the free heap. It makes sense when the allocation rate is constant and there is no reclamation of immediate garbage. However, if we ditch a lot of immediate garbage after the mark, we make the pacer for mark 3x more aggressive without good reason.
Since at least adaptive heuristics starts the cycle so that allocation rate would not deplete the heap soon, we can instead assign 1 of free heap to mark. Leaving 1/2 to evac seems to be fruitful nevertheless: it insulates from oom-evac, and leaves some headroom for update-refs.
Since at least adaptive heuristics starts the cycle so that allocation rate would not deplete the heap soon, we can instead assign 1 of free heap to mark. Leaving 1/2 to evac seems to be fruitful nevertheless: it insulates from oom-evac, and leaves some headroom for update-refs.
- backported by
-
JDK-8247871 Shenandoah: reconsider free budget slice for marking
- Resolved
-
JDK-8248955 Shenandoah: reconsider free budget slice for marking
- Resolved
-
JDK-8249110 Shenandoah: reconsider free budget slice for marking
- Resolved
-
JDK-8250063 Shenandoah: reconsider free budget slice for marking
- Resolved
-
JDK-8250361 Shenandoah: reconsider free budget slice for marking
- Resolved
- duplicates
-
JDK-8247467 Shenandoah: reconsider free budget slice for marking
- Closed
(1 duplicates)