RFR: 8357976: GenShen crash in swap_card_tables: Should be clean [v3]

William Kemper wkemper at openjdk.org
Thu Jun 12 22:47:28 UTC 2025


On Thu, 12 Jun 2025 22:10:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Consolidate read table cleaning"
>   
>   This reverts commit 9552021cbeec699e7b04db81fa68819c23b7dab7.

@pengxiaolong - We don't want to clean the read table during init-mark because that's a safepoint. We can safely clean the read table concurrently because only the GC thread has access to it.

@ysramakrishna - The refactoring you suggest is not so simple, alas. We have to be very careful about the ordering of cleaning the `read` table, resetting the mark bitmap and swapping the card tables. Genshen does not clean the `read` table at the end of a concurrent cycle (we _could_ do this, but we'd still need to do the same in a degenerated cycle). The complexity comes from swapping the card tables in a concurrent cycle. We must not let a subsequent degenerated cycle swap them a second time. The degenerated cycle can only clean the `read` table if there was no active concurrent cycle (lest it throw away critical remembered set data). 

However, the degenerated cycle must also clear the mark bitmaps if the concurrent cycle degenerated during the root scan (the degenerated cycle will rescan the roots). Of course, we cannot clear the mark bitmaps if the concurrent cycle degenerated during the mark phase. So, for the degenerated cycle, clearing the mark bitmaps and cleaning the read table need to happen in two different cases and it doesn't work if they're combined into the same method (and I don't think adding a method parameter to sometimes clear the mark bitmap and sometimes the read table will make the code any easier to understand).

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

PR Comment: https://git.openjdk.org/jdk/pull/25735#issuecomment-2968354749


More information about the shenandoah-dev mailing list