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

[William Kemper]

On Wed, 17 Jan 2024 01:13:50 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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.

Yes, that's my read of it. What I missed earlier is that once any thread fails to evacuate, the other threads are prevented from evacuation. This increases the chances for a degenerated cycle to successfully conclude the evacuation because these other threads may still have memory available in their GCLABs.

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

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