RFR: 8367709: GenShen: Dirty cards for objects that get promoted by safepoint that intervenes between allocation and stores

[Y. Srinivas Ramakrishna]

On Wed, 15 Oct 2025 20:53:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> I believe this sequence of events can lead to the original assertion failing:
> 1. Shenandoah lowers the tenuring threshold to 1.
> 2. An object gets allocated on the slow path.
> 3. We come to a safepoint and run a degenerated cycle.
> 4. The object is evacuated during the degenerated cycle and has its age raised to 1.
> 5. The degenerated cycle is "upgraded" to a full GC.
> 6. The object is at the tenuring age and gets promoted by the full GC into an old region.
> 7. We leave the safepoint and the assertion fails because this "new" object is an old region.
> 
> However, there is still a risk that the card marking barriers have been elided for this object. Now that the object is in the old generation we must be sure that if it ends up storing any pointers to young, then these cards must be dirtied. The solution here is conservative in that it just dirties _all_ the cards for this object. We expect this condition to be rare and the card table will refine itself on subsequent GC cycles. Also, note that we will not scan the remembered set without coming to the `init-mark` safepoint, so it will see these dirty cards.

Good catch of this slippery, if rare, condition. This looks good, but is it possible that we can use a debug `*ALot` type of flag to manually enlarge the post-allocation window so as to induce this condition (promotion) to happen more frequently in fastdebug runs with the flag enabled? That would exercise this code some.

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp line 106:

> 104:   }
> 105: #endif // COMPILER2_OR_JVMCI
> 106:   assert(thread->deferred_card_mark().is_empty(), "We don't use this");

This is rare, so probably not worth the extra work, but there is an existing mechanism to defer this until the safepoint (or until another such deferment arises). Not sure if it's worth using it.

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

PR Review: https://git.openjdk.org/jdk/pull/27832#pullrequestreview-3342585610
PR Review Comment: https://git.openjdk.org/jdk/pull/27832#discussion_r2434156837