Chapter 13 Garbage Collector on Go: Under the Hood

13.1 The Basic Idea of Garbage Collection

Mon, 01 Jan 0001 00:00:00 +0000

13.1 The Basic Idea of Garbage Collection

Garbage collection (GC) frees the programmer from manual free, at the cost that the runtime must decide for itself which memory is still useful and which can be reclaimed. Go’s GC treats low latency as its first priority: it would rather give up a little throughput and memory than let stalls (stop-the-world pauses) grow beyond the sub-millisecond range. This section sets up the theoretical coordinates of GC: reachability, mark-sweep, the tricolor abstraction, and where Go sits within the GC design space. The sections that follow are the elaboration of this basic idea.

13.2 Write Barrier Techniques

Mon, 01 Jan 0001 00:00:00 +0000

13.2 Write Barrier Techniques

13.1 sketched the tricolor abstraction and the outline of concurrent collection: the collector recolors objects from white to grey and from grey to black, driving a “grey wavefront” that advances monotonically across the object graph, and wherever the wavefront has passed is confirmed live. If the mutator (the user-space code) were to halt while the wavefront advances, the abstraction would be self-consistent and would converge correctly. The trouble is precisely that the mutator does not halt. The fundamental difficulty of concurrent collection is this: the collector traces the object graph while the mutator rewrites it, and the two hold conflicting accounts of one and the same graph.

13.3 Trigger Frequency and the Pacing Algorithm

Mon, 01 Jan 0001 00:00:00 +0000

13.3 Trigger Frequency and the Pacing Algorithm

13.2 explained how the write barrier lets concurrent marking coexist with the mutator, guaranteeing that “we can keep allocating even while collection is under way.” That leaves a question of timing: when should the next round of GC start? Too late, and the heap has already grown to an unacceptable size; too early, and frequent collection burns CPU for nothing. The answer comes from the pacer, introduced in Go 1.5 and redesigned in 1.18. This section first lays out the full timeline of a GC cycle, then makes clear what kind of feedback controller the pacer is: it must finish marking before the heap reaches its goal, all while the mutator keeps allocating.

13.4 Scan Marking and Mark Assist

Mon, 01 Jan 0001 00:00:00 +0000

13.4 Scan Marking and Mark Assist

Marking is the main body of GC’s work: starting from the roots (global variables, each goroutine’s stack, registers), it follows pointers and blackens every reachable object (the tricolor abstraction of 13.1). A naive implementation would stop the whole world and walk the object graph single-threaded, which is exactly where early Go’s unbearable pauses came from. After go1.5, marking was reshaped into a form where two things hold at once: it advances concurrently with the user program, and when the user allocates too fast it can amortize the cost onto the allocator itself. This section answers three questions: how marking unfolds in parallel without the workers stepping on each other; how, when scanning an object, we know which of its fields are pointers; and what guarantees that marking will never be left permanently behind while the user allocates and marking chases.

13.5 Sweeping and Bitmaps

Mon, 01 Jan 0001 00:00:00 +0000

13.5 Sweeping and Bitmaps

Once marking (13.4) finishes, any object still white is unreachable garbage. Reclaiming the memory it occupies and handing it back to the allocator is the last step of collection: sweeping. If we followed the textbook recipe of “walk the heap and free dead objects one by one,” the cost of sweeping would be proportional to the number of dead objects, and on a heap with millions of objects that is no small bill. Go’s sweep sidesteps that bill. Three of its design points are worth making clear: sweeping is done by flipping a bitmap rather than processing objects one at a time; it runs concurrently with the user program and lazily spreads its cost across the allocation path; and it does not move objects, so it accepts fragmentation and forgoes compaction. None of these three is accidental. Each corresponds to a definite engineering trade-off, and this section unpacks them one by one.

13.6 Mark Termination Phase

Mon, 01 Jan 0001 00:00:00 +0000

13.6 Mark Termination Phase

Concurrent marking (13.4) carries one nontrivial closing problem: how to decide that marking is complete. In a single-threaded, stop-the-world collector this problem is trivial, the marking thread drains the grey queue and marking is over. But in a concurrent world, “my local queue is empty” never means “there are no grey objects anywhere globally.” The instant a worker goroutine drains its own queue, a mutator on another P may happen to execute a pointer write, the write barrier (13.2) then greys a new object and stuffs it into that P’s local cache. Deciding termination is, in essence, confirming a global property in a system that has no global lock and whose work is scattered across each P’s local cache: the grey set is empty, and no further grey objects will be produced.

13.7 Safe-Point Analysis

Mon, 01 Jan 0001 00:00:00 +0000

13.7 Safe-Point Analysis

The marking phase (13.4) must scan a goroutine’s stack, find every pointer on the stack that points into the heap, and add them to the grey queue as GC roots. This sounds straightforward, but it hides a premise that is easy to overlook: is a given machine word on the stack actually a pointer? A 64-bit word might be a heap address, or it might be an integer that happens to fall within the range of heap addresses, a half-disassembled floating-point value, or a garbage value that has not been written yet. If we mistake a non-pointer for a pointer, we needlessly hold onto a block of memory that should have been reclaimed; if we miss a pointer and treat it as an integer, we reclaim an object that is still in use, and the latter is fatal memory corruption.

13.8 The Generational Hypothesis and Generational Collection

Mon, 01 Jan 0001 00:00:00 +0000

13.8 The Generational Hypothesis and Generational Collection

People who have studied the JVM or .NET often ask a pointed question: why does Go not do generational GC? Generational collection is standard equipment in the GCs of mainstream managed runtimes such as Java and .NET, treated as the key to efficient collection, almost to the point of becoming the common sense of “this is how a modern GC ought to be.” Go pointedly does not adopt it. This section explains the idea of generational collection, its power, and Go’s reasons for not taking this road. The answer here deserves care: it is not that “the Go team did not think of it,” but that the Go team actually implemented a non-moving generational GC, measured its performance, and in the end gave it up. This is a case that powerfully illustrates “there is no design that fits all circumstances.”

13.9 The Request Hypothesis and the Request-Oriented Collector

Mon, 01 Jan 0001 00:00:00 +0000

13.9 The Request Hypothesis and the Request-Oriented Collector

13.8 explained why Go did not adopt the generational hypothesis. The reader may go on to ask: did Go ever try a different “object lifetime hypothesis”? It did. This section is about an experiment the Go team took seriously and ultimately abandoned, the Request-Oriented Collector (ROC). We discuss it not because it made it into Go, but because an abandoned design often reveals where the constraints lie better than a successful one. ROC is like a proof done wrong: the spot where it goes wrong marks exactly the boundary in Go’s GC design space that cannot be crossed.

13.10 Finalizers

Mon, 01 Jan 0001 00:00:00 +0000

13.10 Finalizers

The usual storyline of garbage collection ends at sweeping (13.5): marking finds the live objects, and sweeping returns the slots of dead objects to the allocator. But there is a class of object that wants to say one last word before it dies. It wraps a non-memory resource, a file descriptor, an mmap region, a handle allocated on the C side, and when the Go-side wrapper object becomes unreachable, the underlying resource ought to be released along with it. Garbage collection only understands memory, though, and has no idea that a descriptor needs to be closed. The finalizer is the hook designed for exactly this gap: you register a function for an object, and when garbage collection decides the object is unreachable, the runtime does not free it immediately but first calls that function.

13.11 Past, Present, and Future

Mon, 01 Jan 0001 00:00:00 +0000

13.11 Past, Present, and Future

Having read the previous ten sections, the reader now holds the present state of each part of Go’s garbage collector: tri-color marking (13.1), the hybrid write barrier (13.2), the pacer (13.3), and sweeping and reclamation (13.5). This section takes a different angle: it places these parts back on a timeline and watches how, step by step, they grew into their present shape.

The evolution of the collector reads like a curve that converges steadily in one direction. From Go 1.0 to today, pause times have dropped by roughly two orders of magnitude, and along the way one constant theme runs through it all: every change serves the goal of completing collection without disturbing user code. Once that theme is understood, the many schemes below, both those adopted and those abandoned, can all be measured against the same ruler.

13.12 A Unified Theory of Garbage Collection

Mon, 01 Jan 0001 00:00:00 +0000

13.12 A Unified Theory of Garbage Collection

Having read through this chapter, we have seen Go’s concurrent mark-and-sweep, its hybrid write barrier, and its pacer, and we have set them against other schools of thought such as the generational hypothesis and request-oriented collection. The algorithms come in many flavors, and by this point the reader may have a question building up: beyond the fact that they all “do garbage collection,” is there a common thread that places them inside a single framework?