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

[Y. Srinivas Ramakrishna]

On Wed, 29 May 2024 19:54:05 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> I'll try to trim it down. I shot myself in the foot after being confused by the original comment and deleting this check. Not having this check is not so serious for non-generational modes, but it is necessary to avoid heap corruption and crashes in the generational mode.
>
>> I'll try to trim it down. I shot myself in the foot after being confused by the original comment and deleting this check. Not having this check is not so serious for non-generational modes, but it is necessary to avoid heap corruption and crashes in the generational mode.
> 
> Could you, for the sake of completeness, document this specific _generational pathology_ in the ticket, because it might bring up some interesting thinking about the ways in which the two modes might interact wrt the existing structure of the state machine driving the progress of the collections in the two cases, and the presence of asynchronous interruptions of that normal state machine flow/transitions.

> @ysramakrishna , during init mark, the generational mode copies the cards that have been used by the barrier up until init mark (the 'write' card table) onto a read only copy used by the concurrent mark (the 'read' table) and resets the write table. Mutators continue using the fresh write table. However, the concurrent mark workers are also responsible for _rebuilding_ the write table. If the concurrent mark is cancelled, the write card table may not be complete. If the degenerated cycle resets the card table (as it would without this check), portions of the card table may be lost.

Makes sense; thanks for the explanation.

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

PR Comment: https://git.openjdk.org/jdk/pull/19434#issuecomment-2140531489