Why can a tracing collector not reclaim an object that your program will never read again?

## Two different questions When memory that ought to be free is not, two questions are being confused: 1. **Is this object still reachable?** A property of the heap graph as it stands. Computable by a walk from the roots. 2. **Will the program ever read this object again?** A property of every execution the program might still have. Not computable in general. A tracing collector answers the first and uses it as a stand-in for the second. The substitution is deliberately conservative in one direction: an unreachable object is definitely never read again, so reclaiming it is always safe; a reachable object *might* be read, so retaining it is always safe. The collector never frees something you could still touch — and it also never frees something you could touch but won't. ## Why the second question is not computable Suppose a collector could decide, for any object and any program state, whether some later instruction reads that object. Then for an arbitrary program you could allocate an object, arrange for it to be read only on the line after an arbitrary computation finishes, and ask the collector; its answer would tell you whether that computation terminates. That is the halting problem. Individual cases are of course decidable — a compiler routinely proves that a stack slot is never read after a certain instruction — but there is no general procedure, so the runtime cannot have one. ## The four combinations | Reachable from a root? | Program will read it again? | What happens | Name for it | |---|---|---|---| | Yes | Yes | Retained, correctly | Ordinary live data | | Yes | No | Retained anyway | **Logical leak** — the gap | | No | No | Reclaimed | Ordinary garbage | | No | Yes | Impossible | The program has no way to name it | The fourth row is what makes the approximation sound: a program cannot read what it cannot name, and it cannot name what no root path reaches. ## What the gap looks like from inside - A reference sits in a structure whose own lifetime is tied to a root, so the object inherits that lifetime rather than the one it deserves. - The retained object is not the cost — the **closure behind it** is. One small reachable object can hold a graph orders of magnitude larger. - Memory use tracks the *accumulated* set of such references, so the symptom is a floor that rises over time rather than a spike. - Nothing anywhere reports an error: from the collector's point of view every object it kept was genuinely reachable, and it was right about all of them. ## What actually fixes it 1. **Cut the path.** Remove the reference from whatever structure still holds it, so the next trace does not reach the object. 2. **Bound the holder.** Give the structure that accumulates references a size or time limit, so old entries are dropped as a matter of policy rather than hope. 3. **Shorten the root's own life.** If the retaining structure is itself reachable only from something that should have ended, end it. ## What does not fix it - **Forcing a collection.** The collector will make exactly the decision it made last time: reachable, therefore retained. - **A larger heap.** It changes when the problem becomes visible, not whether it exists; an accumulating live set overruns any fixed bound eventually. - **Clearing a local slot on the way out of a function**, in most cases. That helps only when the slot holds the last remaining path to the object *and* the compiler has not already stopped reporting the slot as live after its final read. If any other reachable structure still references the object, clearing one slot changes nothing at all. The discipline to carry away is that in a collected runtime, "a leak" is never a collector defect. It is a statement about your own object graph: something you still point at, and no longer need.