RFR: 8333105: Shenandoah: Results of concurrent mark may be lost for degenerated cycle [v2]

[William Kemper]

On Thu, 30 May 2024 18:25:27 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> This case doesn't quite follow the `check_cancellation` pattern of the others because it is a little bit different. Here, the uninterruptible operation is the final mark safepoint. This safepoint will itself check if the mark has been cancelled. If final mark detects the cancellation, it will do _nothing_, the concurrent mark will still be in progress and we _must_ resume the degenerated cycle from the marking phase. However, if the final mark safepoint does _not_ detect a cancellation, it will initialize the evacuation phase. If the code simply `checks_cancellation` after final mark it cannot tell if the cancellation request was received just _before_ final mark or just _after_ final mark. These two conditions require different resumption points for the degenerated cycle, so we must check the state of the collection cycle here.
>
> Thanks for the explanation. I do wonder if there's a one-to-one bijection between the interrupt/cancellation detection point and the resumption point for the degeerated cycle. If that is true, then the resumption point may be identified with the state of the concurrent GC state machine (the degeneration work is in a coupled state machine in the sense of David Harel) and might avoid this more subtle and perhaps a little bit more fragile programming idiom. But we can think about this in the fullness of time.

Yes, it would be great to clean up the state hand-off from concurrent to degenerated cycles. The generational mode also introduced a new `_degenerated_roots` state to avoid double-resetting of the write card table.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19434#discussion_r1621275897