RFR: 8323634: Shenandoah: Document behavior of EvacOOM protocol [v3]

Kelvin Nilsen kdnilsen at openjdk.org
Wed Jan 17 01:16:52 UTC 2024


On Tue, 16 Jan 2024 21:46:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Is this true?  I believe degenerated cycle is unable to recover from OOM during evac.  We always have to upgrade to Full GC in this situation.  That's because the OOM during Evac protocol has compromised the cset by possibly allowing references to the cset to sneak through the LRB barrier.  Hereafter, degen is not sufficient to recover.
>
> Yes, this happens. That is why we specifically has to add this patch: https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp#L202 to help the degenerated cycle recover from oom-during-evac correctly.

I am wrong about this.  So if the _degen_point is _degenerated_evac, the degenerated evac cycle sets the update watermark value on every active region to the current top (because we may need to rescan ranges of regions that are above the original update watermark because we may have written a leaked cset pointer into this memory) and then we iterate through all cset regions to evacuate all objects not previously evacuated.  There is no attempt by degen gc to resume evacuation where concurrent GC left off.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17385#discussion_r1454297384


More information about the hotspot-gc-dev mailing list