-
Enhancement
-
Resolution: Fixed
-
P4
-
8-shenandoah, 11-shenandoah, 14, 15
-
b12
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8240460 | 14.0.2 | Aleksey Shipilev | P4 | Resolved | Fixed | b01 |
In some unlucky cases, when several successive Degen/Full GC happened, we accumulate a lot of penalties. It would then take a lot of successful concurrent GCs to recuperate from this.
Currently, degen and full GC would incur 10%*capacity and 20%*capacity penalty, and successful concurrent GC recuperates 1%*capacity. But penalties are not range-checked! So 50 degen GCs would tank penalties to about 500%*capacity, like this:
[53644.733s][info][gc ] Trigger: Average GC time (401.43 ms) is above the time for allocation rate (4954 KB/s) to deplete free headroom (0B)
[53644.733s][info][gc,ergo] Free headroom: 3973M (free) - 307M (spike) - 30351M (penalties) = 0B
...and it would take about 400 concurrent cycles to even get to the point where penalties are not eating up the entire capacity.
We should really range-check penalties and saturate them to 100%.
Currently, degen and full GC would incur 10%*capacity and 20%*capacity penalty, and successful concurrent GC recuperates 1%*capacity. But penalties are not range-checked! So 50 degen GCs would tank penalties to about 500%*capacity, like this:
[53644.733s][info][gc ] Trigger: Average GC time (401.43 ms) is above the time for allocation rate (4954 KB/s) to deplete free headroom (0B)
[53644.733s][info][gc,ergo] Free headroom: 3973M (free) - 307M (spike) - 30351M (penalties) = 0B
...and it would take about 400 concurrent cycles to even get to the point where penalties are not eating up the entire capacity.
We should really range-check penalties and saturate them to 100%.
- backported by
-
JDK-8240460 Shenandoah: accumulated penalties should not be over 100% of capacity
- Resolved