HotSpot's Serial collector compacts the old generation rather than leaving a free list behind. Walk through the phases of that mark-compact collection and explain how references are fixed up after objects move.

## Why compact at all A collector that merely marks and sweeps leaves the survivors where they are and threads the gaps onto a free list. That is cheap, but it fragments: after enough cycles the old generation can hold plenty of free bytes and still fail to satisfy a single large allocation or a promotion, because no individual gap is big enough. Compaction removes that failure mode entirely by pushing live objects together, leaving one contiguous free region. The price is that objects **move**, and every reference to them must be found and rewritten. The Serial old collector pays that price on every full GC. Its algorithm is the classic *sliding* compaction (often called Lisp2), chosen because it preserves the original allocation order of objects — which tends to keep related objects near each other and is friendly to the CPU cache — and needs no extra side table proportional to the heap. ## Phase 1 — Mark All application threads are stopped at a safepoint. Starting from the root set (thread stacks and registers, static fields, JNI global references, and similar), the collector performs a transitive traversal of the object graph, setting a bit in each reachable object's header to mark it live. A marking stack holds pending work; if it overflows, the collector falls back to rescanning, which is slower but bounded. A detail that matters: the object header (mark word) is about to be commandeered for forwarding addresses in the next phase, but for some objects it holds information that must survive — an installed identity hash code, or lock state for an inflated monitor. Those headers are pushed onto a **preserved marks** stack, paired with the object, and restored at the very end. ## Phase 2 — Compute new addresses The collector now walks the old generation **in address order**, keeping a running "next free destination" cursor that starts at the bottom of the space. For each live object it encounters, it records the current cursor value into that object's header as a **forwarding pointer** and advances the cursor by the object's size. Dead objects are skipped, so the cursor lags behind the scan position by exactly the amount of garbage passed so far. At the end of this pass, every live object knows where it is going, but nothing has moved yet and no reference has changed. Because the walk is in address order and the cursor is monotonic, relative order is preserved — objects slide down, they never reorder. ## Phase 3 — Adjust pointers Now the collector rewrites references. It visits every root and every reference field inside every live object; for each reference it loads the referent's header, reads the forwarding address stored there in phase 2, and writes that address back into the field. It also fixes references from *outside* the old generation that point into it — the young generation's live objects and any remembered-set-recorded slots. After this pass the heap is in a temporarily inconsistent but well-defined state: every reference names the object's *future* address, while the object still physically sits at its old one. Nothing may run except the collector until phase 4 completes. ## Phase 4 — Move Finally the collector walks live objects in address order again and copies each one down to its recorded destination. Because destinations are always at lower addresses than sources and the walk proceeds upward, a simple forward memory move is safe even when source and destination overlap. Preserved headers are then restored from the stack, and the space's top-of-allocation pointer is set just above the last moved object. ## What you are left with — and what it costs The old generation is now dense at the bottom with one contiguous free block above it, so the next promotion or large allocation is a pointer bump and cannot fail for fragmentation reasons. Allocation locality is preserved. The cost is that all four phases are stop-the-world and single-threaded. Phases 2 and 4 sweep the entire space (so their cost tracks *heap size*), while phases 1 and 3 track the *live set* and the number of reference fields in it. That is why full-GC pause time in the Serial collector rises roughly with how much live data you keep, and why the collector is a poor fit for multi-gigabyte heaps with large live sets — there is no second thread to split the work across, and nothing runs concurrently with the application. The same algorithm is what makes Serial predictable: no fragmentation-driven surprises, no concurrent-cycle races, no fallback modes. You get one behaviour, and it is easy to reason about.