A concurrent marker must never free a reachable object; how would you build confidence that its tri-colour invariant actually holds?

## Why this defect does not behave like a normal bug A broken invariant does not fail where it happens. The marker finishes, the sweep hands back memory that is still referenced, the space is handed out again, and two unrelated parts of the program begin writing over one another. The observable symptom arrives minutes or hours later, in code that is entirely innocent, and it depends on a window measured in instructions. Three consequences follow immediately: - absence of failures is weak evidence, because the interleaving is rare and testing samples schedules rather than enumerating them; - the stack trace at the point of failure is actively misleading; - the defect is more likely to sit in the *edges* of the design — a store path nobody instrumented — than in the barrier logic everyone reviewed. So the strategy is not "test harder". It is to turn an invisible property into an assertion, and to reduce the space in which a bypass can hide. ## Three lines of defence 1. **Assert the property itself.** In a build reserved for verification, end each cycle with the program stopped, re-trace from the roots synchronously, and check that every reachable object is marked. Optionally walk the heap for edges from scanned objects to unreached ones while the trace is still in progress. This is expensive and that is acceptable: it converts a silent state into a failure at the moment of violation, naming the object and the cycle. 2. **Choose the schedule rather than the load.** Add hooks that let a test suspend the marker at chosen points and perform exactly the mutation that threatens the invariant, then resume. Exhaustively explore interleavings on small graphs — a handful of objects is enough to cover the hazard — and model-check the barrier as a state machine. This finds in seconds what a random workload might never produce. 3. **Prove there is no bypass.** Funnel every reference write through one construct, and audit everything that can write a reference without going through it: bulk copy routines, initialisation fast paths, code emitted by an optimiser, and anything that hands raw memory to an external interface. ## What each method actually catches | Method | Catches | Misses | |---|---|---| | Long soak testing | gross errors that fire often | the rare interleaving, which is the whole problem | | End-of-cycle verification build | any cycle that left a reachable object unmarked | violations in configurations that build is never run on | | Directed interleaving tests | the hazard the test author imagined | hazards nobody thought to script | | Exhaustive small-graph checking | logic errors in the barrier itself | integration errors outside the barrier | | Store-path audit | the missing-hook class of defect | a hook that is present but wrong | The table is the argument for using several: each column-two entry is another's column three. The pairing that covers the most ground for the least effort is the verification build plus the store-path audit, because between them they cover "the barrier was wrong" and "the barrier was not there". ## The bypass problem deserves its own attention Most real defects of this class are not subtle mistakes in the shading rule. They are stores that never ran it. That is a structural problem, and it has structural answers: generate the barrier rather than hand-writing it at each site; make the raw store operation inaccessible outside a small, reviewed module; add a build-time check that flags any reference write outside the sanctioned path. Treat removing a barrier — even on a store that "obviously" cannot matter — as a correctness change that needs the same scrutiny as the collector itself, never as a local optimisation. ## When a suspicion is live Keep the ability to mark with the program stopped, always. It costs pauses and it costs nothing else, and it is the single most useful diagnostic you will own: - run the failing workload with concurrent marking disabled; if the corruption disappears, the invariant's enforcement is the prime suspect; - if it persists, the collector is probably not the cause at all, which is just as valuable to know; - ship the fallback as an operational switch so the fleet has a mitigation while the investigation runs. Be explicit about what the switch costs, though. Trading a rare corruption for a long, predictable pause is usually the right call for a short window, and it is a decision to make deliberately rather than under pressure at three in the morning. ## What the judgment actually is The open question is not which techniques exist; it is how much verification the risk warrants. Reasonable positions differ by blast radius: a runtime that many teams depend on can justify exhaustive checking and a permanently maintained verification build, while a narrower system may reasonably settle for assertions plus a bypass audit. What is not defensible at any scale is confidence derived from a quiet week, because a quiet week is precisely what this defect class produces right up until it does not.