Why can the largest free block keep shrinking in a heap whose manager is able to relocate objects to consolidate free space?

## Consolidation depends on permission to move A manager that relocates objects fixes shattered free space by copying live objects together and leaving one large run behind. Moving an object means copying its bytes and then updating **every reference that points at it**, so they name the new address. The manager can do that for references it knows about: fields of other objects, the roots it enumerates, its own bookkeeping. It cannot do it for an address that has escaped that bookkeeping — one written into a structure outside the managed heap, or handed to a device or kernel transfer that will read it later. For as long as such an address is outstanding, the object must stay exactly where it is. That state is **pinning**. ## What ends up pinned - Buffers whose address was handed to an outside transfer, for the duration of that transfer. - Objects reachable from a foreign structure that the manager does not walk and cannot rewrite. - Objects the manager has decided not to move on cost grounds — very large ones in particular, where copying would dominate the cycle. - Objects pinned by an explicit request in the program, for as long as the program holds the pin. The first of these is usually short-lived and harmless. The damage comes from **long-lived** pins, and from pins spread thinly across many units. ## One immovable tenant strands a whole unit Relocating managers work a unit at a time. To free a unit they evacuate every live object out of it and then take the whole unit back as one run. The rule is all-or-nothing: 1. Pick a unit with little live data — a good candidate, because evacuation cost is proportional to what must be copied. 2. Copy each live object out to a destination unit and fix the references that named it. 3. If even one object cannot be copied, the unit cannot be emptied. Its free space stays where it is: split, scattered, and separate from every other unit's free space. A heap with a few percent of its units pinned loses far more than a few percent of its consolidation ability, because the manager chooses units by how little is live in them, and a pinned buffer sitting in an otherwise empty unit is exactly the candidate it wanted. The measurable result is the signature this leaf is about: **total free flat, largest contiguous free block falling**. | Observation | Plain hole accumulation | Pins blocking consolidation | |---|---|---| | Manager relocates objects | Consolidation recovers runs each cycle | Consolidation runs and recovers little | | Largest free block after a cycle | Rises back towards its old value | Stays flat or keeps falling | | Correlation | Broad; grows with uptime | Tracks the phases that hand addresses out | ## How to confirm it - Compare the free bytes before a consolidation pass with how much the pass actually merged. A large gap means the pass was blocked, not idle. - Count units the manager skipped as unevacuatable, where it reports that. A rising count is direct evidence. - Correlate the failures with the phases that hand object addresses to outside transfers. A symptom that tracks that traffic, rather than uptime alone, points at pins. - Route the transfers through a copy into space the manager never relocates, and see whether the largest free block recovers. A change that makes the symptom disappear is the strongest evidence available from outside the code. ## Why this one is easy to miss The intuition that a relocating manager cannot suffer from shattered free space is nearly right, and nearly right is the dangerous kind. It holds for ordinary objects and fails for exactly the objects a program is most likely to make large: the buffers it shares with the outside world. Those are simultaneously the biggest, the most likely to be pinned, and the ones whose allocation fails first when large runs run out. A service can therefore be failing on precisely the allocations that its own pinning behaviour made impossible, while every graph on the wall says the heap has room. The practical rule that follows is to keep pins short and few, and to **concentrate** what must be immovable instead of scattering it. A small set of long-lived buffers reused for every transfer strands a small, fixed set of units; a fresh pinned buffer per request strands a new unit each time and leaves the manager with steadily less it is allowed to touch. Ecosystems differ in how much of this they expose — some make pinning explicit and bounded, others do it implicitly on your behalf — but the accounting is the same everywhere: consolidation can only reclaim what it is permitted to move.