Summary
emit_parent_may_need_remembering_check emits a seq_cst load of @PERRY_INCREMENTAL_MARK_BARRIER_ACTIVE_COUNT — an ldar on aarch64 — while the runtime reads the same global Relaxed for the same decision, and codegen's own documentation for the site says "one relaxed load of a static".
evalNode in gc-handoff/apps/interp.ts has 42 barrier sites, and the ldar is visible in the profile.
Why this is filed rather than fixed
Found while working #7907 (PIC miss-block dominance) and deliberately left alone: the failure mode of getting this wrong is a missed insertion barrier, i.e. a live object never shaded during incremental marking, which is silent at collection time and surfaces cycles later in an unrelated function as TypeError: value is not a function. That is the hardest class of bug in this codebase to diagnose, so the ordering question wants an explicit owner decision rather than a performance-motivated guess.
The question to answer
Is Relaxed sufficient here, given:
- the runtime already reads the same global
Relaxed for the same decision — so today the two sides disagree about the required ordering, and at most one of them is right;
- what, if anything, this load is intended to be ordered against (the write that arms the barrier, versus the subsequent heap store);
- whether the arming side uses a
Release store that a Relaxed acquire-side load would fail to pair with.
If Relaxed is correct, codegen should match the runtime and its own doc. If seq_cst is correct, the runtime side is the bug and is far more serious than the performance cost.
Either way the current state — two readers of one global disagreeing on ordering, with the documentation siding against the code — should not persist.
Evidence
gc-handoff/INTERP8-NOTES.md; the site is in the write-barrier emission path in perry-codegen.
Summary
emit_parent_may_need_remembering_checkemits aseq_cstload of@PERRY_INCREMENTAL_MARK_BARRIER_ACTIVE_COUNT— anldaron aarch64 — while the runtime reads the same globalRelaxedfor the same decision, and codegen's own documentation for the site says "one relaxed load of astatic".evalNodeingc-handoff/apps/interp.tshas 42 barrier sites, and theldaris visible in the profile.Why this is filed rather than fixed
Found while working #7907 (PIC miss-block dominance) and deliberately left alone: the failure mode of getting this wrong is a missed insertion barrier, i.e. a live object never shaded during incremental marking, which is silent at collection time and surfaces cycles later in an unrelated function as
TypeError: value is not a function. That is the hardest class of bug in this codebase to diagnose, so the ordering question wants an explicit owner decision rather than a performance-motivated guess.The question to answer
Is
Relaxedsufficient here, given:Relaxedfor the same decision — so today the two sides disagree about the required ordering, and at most one of them is right;Releasestore that aRelaxedacquire-side load would fail to pair with.If
Relaxedis correct, codegen should match the runtime and its own doc. Ifseq_cstis correct, the runtime side is the bug and is far more serious than the performance cost.Either way the current state — two readers of one global disagreeing on ordering, with the documentation siding against the code — should not persist.
Evidence
gc-handoff/INTERP8-NOTES.md; the site is in the write-barrier emission path inperry-codegen.