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

Y. Srinivas Ramakrishna ysr at openjdk.org
Wed Oct 15 22:58:03 UTC 2025


On Wed, 15 Oct 2025 22:51:23 GMT, Y. Srinivas Ramakrishna <ysr 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.
>
> 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.

Probably not worth the trouble, because that mechanism might require wiring in some other stuff which may not be wired in for GenShen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27832#discussion_r2434162161


More information about the shenandoah-dev mailing list