FA-90348 / Garbage collector invariants / Member archive

Insertion barrier: objects allocated during marking start white · case 03

Freshly allocated objects are swept at the end of the cycle in which they were created.

Member previewVariant 3 · 3 implementations · 7 checks per implementation

Case contract

Incremental tri-colour mark-sweep with a Dijkstra insertion barrier. start: every object white, roots shaded grey. mark k: up to k worklist steps (pop a grey object, shade its white children, blacken it). store src i dst: while marking, shade dst before writing. alloc id k: new object with k null fields, black while marking (allocate-black), otherwise white. root id: add a root, shaded if marking. unroot id removes a root. finish: drain the worklist, free all white objects, stop marking. Return the freed ids per finish and the surviving ids.

Why this case matters

Incremental collectors are only safe if barriers and allocation colour preserve the tri-colour invariant.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixture	Actual	Expected	Outcome
allocation after the worklist drained	`{"freed": [[34, 35, 36, 37]], "live": [31, 32, 33]}`	`{"freed": [[34, 35, 36]], "live": [31, 32, 33, 37]}`	Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.