You are choosing between a moving collection strategy (copying or compacting) and a non-moving one (mark-sweep) for a runtime. Lay out the trade-offs that decide it, including effects on the allocation path, fragmentation risk, and code that holds raw object addresses.

## Why this is a real design fork "Does the collector relocate surviving objects?" is the single decision that most shapes a memory manager. It determines the allocation instruction sequence, the failure modes under long uptime, the constraints on the rest of the runtime, and the shape of pauses. ## The allocation path After a moving collection, free memory is contiguous. Allocation reduces to: read a pointer, add the size, compare against a limit, store. It parallelises trivially by giving each thread its own buffer carved from the contiguous space, so the common path needs no synchronisation. Initialisation is also cheaper because freshly bumped memory is contiguous and cache-friendly. A non-moving heap cannot offer this. Free memory is a set of holes, so the allocator maintains size-class lists, must choose a fitting hole, and must coalesce neighbours to fight fragmentation. Every one of those is more instructions on the hottest path in a managed runtime, and each is harder to make lock-free. ## Fragmentation as a long-run failure mode Fragmentation is not merely wasted bytes. Its practical signature is an allocation failure for a large contiguous object while total free memory is comfortable, arriving after days of uptime and after all the load testing passed. A non-moving design must have an answer: either a compaction fallback (correct but a long pause exactly when the system is already under pressure), size-segregated allocation that bounds worst-case waste, or an application-level guarantee about object size distribution - which is rarely available. ## The cost model Moving costs are proportional to what survives. Copying an area where 2% survives is nearly free; compacting an old generation that is 85% live is close to worst case, because almost everything is read, written, and re-pointed to reclaim little. Non-moving sweeping is proportional to heap size and is indifferent to survival rate. This asymmetry is why generational designs apply copying where survival is low and something else where it is high, rather than picking one strategy for the whole heap. ## The constraints moving imposes on the rest of the runtime 1. **Precision.** A non-moving collector can be conservative: if a stack word might be a reference, treat it as one; the only harm is retaining an object slightly too long. A moving collector cannot guess - rewriting a word that was actually an integer corrupts data. So it needs precise stack maps and object layout maps, and it can only relocate at points where those maps are valid, which is what safepoints are for. 2. **Native code.** Code outside the managed world may hold raw addresses. Options are pinning (the object cannot move while a native reference exists), handle indirection (native code holds a slot that the collector updates), or copying data across the boundary. All of them impose API design constraints. 3. **Header state.** Identity hash codes must remain stable even though addresses change (typically by materialising and storing a hash on first use), and lock or monitor state must travel with the object. 4. **Reference-holding structures elsewhere.** Anything caching an address rather than a reference - certain off-heap indexes, some JIT-compiled constants - needs an update protocol. ## Reading the workload - Very high allocation rate with very low survival: moving is strongly favoured; the collection is cheap and the allocation path is the hottest code in the system. - Large, dense, long-lived live sets: the reward for moving shrinks while its cost grows; incremental or region-wise relocation becomes preferable to whole-space compaction. - Heavy native interop with long-lived direct pointers: the pinning/handle burden pushes toward non-moving, or toward a design with an explicit pinning region. - Mixed and unpredictable object sizes with multi-month uptime: fragmentation risk pushes toward having compaction available, whether continuous or as a fallback. ## The answer to actually give A principal-level answer refuses to declare a winner and instead states the decision rule: relocate where survival is low and the allocation path dominates cost; avoid relocating where the live set is dense or where external code depends on address stability; and never ship a non-moving design without an answer for the day fragmentation blocks a large allocation. Note also that the choice is not global - real systems apply different strategies to different parts of the heap, which is exactly why generational and region-based designs exist.