gc/codegen: barrier-active load is seq_cst in codegen but Relaxed in the runtime — the two readers disagree on ordering

[proggeramlug]

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.