-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
tbd
Long-shot experiment in https://github.com/openjdk/jdk/compare/master...shipilev:wip-shenandoah-full-gc-be-gone
We have added Shenandoah Full GC for several reasons, most of which boil down to providing the emergency GC that can recover the heap from any condition. This often gets in the way when adding new code to Shenandoah, as we would need to figure out how Full GC works for it. Full GCs are rare in real use. It is fairly likely that Generational mode would make them even rarer.
It would be more convenient to manage without Full GC.
Currently, there are several paths which lead to Full GC:
1. OOM during evac: we assume the memory is either extra tight or fragmented, and only a sliding GC would recover enough of the memory to continue normal operations. Additionally, OOM-evac leaves heap in half-forwarded state, since collection set was not fully evacuated.
2. Humongous fragmentation: normal GC does not move humongous objects, and only sliding GC is able to compact humongous objects efficiently.
I think we can handle both in degenerated GC.
For OOM-evac, we can restart the degen cycle, fix up the heap as we mark, and then hopefully declutter enough space to continue. We might want to tame the cset selection during restarting degen a bit, so that we do not run into OOM-evac again.
For humongous moves, we can still do a limited compaction straight in degen, record the moves into humongous fwdptrs, and leave the update references phase to fix up the references after the move.
We have added Shenandoah Full GC for several reasons, most of which boil down to providing the emergency GC that can recover the heap from any condition. This often gets in the way when adding new code to Shenandoah, as we would need to figure out how Full GC works for it. Full GCs are rare in real use. It is fairly likely that Generational mode would make them even rarer.
It would be more convenient to manage without Full GC.
Currently, there are several paths which lead to Full GC:
1. OOM during evac: we assume the memory is either extra tight or fragmented, and only a sliding GC would recover enough of the memory to continue normal operations. Additionally, OOM-evac leaves heap in half-forwarded state, since collection set was not fully evacuated.
2. Humongous fragmentation: normal GC does not move humongous objects, and only sliding GC is able to compact humongous objects efficiently.
I think we can handle both in degenerated GC.
For OOM-evac, we can restart the degen cycle, fix up the heap as we mark, and then hopefully declutter enough space to continue. We might want to tame the cset selection during restarting degen a bit, so that we do not run into OOM-evac again.
For humongous moves, we can still do a limited compaction straight in degen, record the moves into humongous fwdptrs, and leave the update references phase to fix up the references after the move.