Concurrent Collection Barrier¶
Synchronization protocol — instantiates Reachability-Guided Resource Reclamation
Intercepts reference writes while the collector runs so the mutator can keep working without corrupting the in-progress reachability view.
A reachability trace assumes the reference graph holds still while it walks. Concurrent Collection Barrier is what lets that assumption survive being false. It is a small piece of machinery inserted on the mutator's reference writes: while a collection is in progress, whenever running code changes a reference, the barrier records the change so the collector cannot be tricked into missing a resource that became reachable mid-trace. This is the correctness contract that makes it safe for the application (the mutator) and the collector to touch the same reference graph at the same time, rather than stopping the world for the whole trace. The barrier does not decide what is reachable and does not free anything; it protects the integrity of the in-flight reachability view against concurrent mutation.
Example¶
A Go service is handling live traffic when a garbage collection begins. Go's collector marks reachable objects concurrently, so goroutines keep allocating and rewriting pointers while the mark is underway. The danger is a specific race: the collector has already scanned object A and moved on, and now the running code stores into A the only reference to a freshly created object B, then erases every other path to B. Without protection, the collector — having finished with A — would never revisit it, never mark B, and would sweep B away while A still points at it: a use-after-free. Go's write barrier closes this hole. When the store into A happens during marking, the barrier shades B so the collector is guaranteed to visit it. The application never pauses for the trace; it only pays a few instructions on each pointer write. The correctness rests on the tricolor marking invariant.[n1]
How it works¶
The collector colors resources: white (not yet proven reachable), grey (reachable, not yet scanned), black (reachable and fully scanned). The trace advances by scanning grey resources black. The barrier's job is to preserve the invariant that no black resource holds the only reference to a white one. On each reference write during a cycle it intervenes — either shading the newly referenced resource grey (an incremental-update barrier) or recording the overwritten reference so it is still traced (a snapshot-at-the-beginning barrier). Brief stop-the-world pauses bracket the cycle to scan roots and to terminate marking; everything between runs concurrently. The collection cycle itself is an epoch, and the barrier is only armed within it.
Tuning parameters¶
- Barrier discipline — snapshot-at-the-beginning versus incremental-update. Snapshot barriers retain everything live at the cycle's start (more floating garbage, simpler termination); incremental-update barriers track newly installed references (less floating garbage, subtler termination).
- Pacing / trigger — how much heap growth is allowed before a concurrent cycle starts. Start late and the mutator may outrun the collector and exhaust memory; start early and you burn CPU on collection headroom.
- Root-scan slice size — how much of the brief stop-the-world work is chunked, trading pause length against total overhead.
- Barrier placement — write-only versus read-and-write barriers, trading per-access cost against which mutations must be intercepted.
When it helps, and when it misleads¶
Its strength is latency: the mutator keeps running through almost the entire collection, so pauses shrink from "proportional to the live set" to a couple of short bracketing stops — indispensable for interactive and low-latency systems. Its costs are real and subtle. Every reference write pays the barrier tax whether or not a collection is running its hottest path. It produces floating garbage: resources that die after the barrier has already preserved them survive to the next cycle. And its correctness is brittle — a single missed barrier is a latent use-after-free that may not surface for months. The classic misuse is hand-rolling concurrent reclamation and omitting a barrier on some exotic write path. The guarding discipline is to treat the tricolor invariant as an inviolable contract enforced on every mutating path, verified rather than assumed.
How it implements the components¶
reachable_closure_record— the grey/black marking state is a live closure that the barrier keeps consistent even as the graph mutates underneath it; without the barrier that record would be corrupt.pending_finalizer_and_inflight_protection— resources the mutator is actively wiring up during a cycle are protected from reclamation, so an in-flight-reachable resource is never freed out from under running code.synchronization_and_epoch_rule— the barrier plus the collection-cycle epoch are the synchronization rule that lets collector and mutator share one reference graph safely.
It does not enumerate the authoritative_root_set or the resource_universe_boundary — establishing those belongs to tracing_mark_sweep_cycle, whose trace this barrier makes concurrent — and it does not classify edges as owning or non-owning (edge_semantics_policy); the barrier only records *that a reference changed, leaving the meaning of edges to weak_reference_registry.*
Related¶
- Instantiates: Reachability-Guided Resource Reclamation — supplies the concurrency-safety contract that lets reclamation proceed without freezing the system.
- Consumes: tracing_mark_sweep_cycle — the barrier exists to let that mechanism's trace run beside a live mutator.
- Sibling mechanisms: reference_counting · generational_collection · cycle_detection_pass · dry_run_reclamation_report · lease_expiry_sweep · reachability_graph_visualization · tombstone_then_delete · weak_reference_registry
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Intercepts reference writes while the collector runs so the mutator can keep working without corrupting the in-progress reachability view, making its operative form a live operational control that automatically routes, enforces, adapts, or responds during execution.
Independent corroboration: The frozen evidence defines Concurrent Collection Barrier as 'Intercepts reference writes while the collector runs so the mutator can keep working without corrupting the in-progress reachability view', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Garbage-collection research cohered write barriers and the tricolor invariant so mutators can run while reachability is traced safely.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] The tricolor marking invariant (Dijkstra, Lamport, and colleagues): partition resources into white, grey, and black and never allow a black resource to hold the sole reference to a white one. Concurrent barriers exist precisely to maintain this invariant while the graph mutates. ↩