RFR: 8357550: GenShen crashes during freeze: assert(!chunk->requires_barriers()) failed
William Kemper
wkemper at openjdk.org
Thu Jun 19 21:32:28 UTC 2025
On Thu, 19 Jun 2025 20:55:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> Shenandoah captures a preliminary top-at-mark-start (TAMS) concurrently. Once concurrent marking has begun, any object beneath TAMS requires a barrier when accessed. The implementation of `ShenandoahHeap::requires_barrier` does not distinguish between _old_ and _young_ marking. This could lead to a race between freezing the stack and capturing TAMS:
>>
>> 1. Collector is marking old
>> 2. Allocate stack chunk in young
>> 3. Barrier is not needed, begin fast freeze path
>> 4. Collector concurrently updates TAMS (young marking will start once init-mark safepoint is reached)
>> 5. ShenandoahHeap now thinks the barrier is needed (because TAMS changed, and we are marking old)
>> 6. Fast freeze asserts out
>>
>> This fix has the generational mode check the appropriate generation and its marking state. It also enforces barriers for stackChunks in the old generation (for card marking).
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 191:
>
>> 189: }
>> 190:
>> 191: if (is_concurrent_young_mark_in_progress() && is_in_young(obj) && !marking_context()->allocated_after_mark_start(obj)) {
>
> Just so I understand (and maybe this deserves a clarifying comment to help others understand):
> The barrier we are concerned about here is SATB. If obj is above TAMS, there's no need to enforce a SATB barrier. Any reference residing above TAMS which is overwritten will have been marked already, or is about to be marked. Either the value is already "presumed marked" because it also resides above TAMS, or its value was assigned from a root (in which case root scanning marked it), or it was copied from a pre-existing object (in which case it will be marked by scanning of that pre-existing object or by SATB).
Yes, concerned about SATB here.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25905#discussion_r2157677596
More information about the shenandoah-dev
mailing list