Go: Under the Hood

Preface

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

Preface

The Go language has a history of more than a decade since it first appeared in 2009. Looking across the history of most programming languages, what is surprising is that over the dozen or so years Go has evolved, the language itself has not changed all that much, and Go users have been able to keep writing applications that remain backward compatible. From the standpoint of language design, Go was built from the very beginning around principles such as low cost, high concurrency, and simplicity, and it is hard not to be curious about the implementation mechanisms and the concrete working principles that sit behind that simple design. This book is one that discusses the technical principles in the Go source code and the course of their evolution.

How to Read This Book

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

How to Read This Book

A reader once told the author that this book is hard going. They had studied Go and used it for a few years, yet when they hit the chapters on scheduling, stealing, and memory, they could still only talk in the abstract. That feedback is sincere, and the author accepts it. Part of the depth this book aims for comes from decades of accumulated work in systems, concurrency, and compilation, and the slope really is steep on first contact. But steep does not mean the only option is to grind through it. What a book can offer is a few paths that make the slope gentler. This page is about how to walk those paths.

1.1 The Evolution of Programming Languages

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

1.1 The Evolution of Programming Languages

To understand why Go turned out the way it did, why it is so restrained, so obsessed with compilation speed, so concerned with concurrency, we first have to look at the language landscape it was born into, and at whose pain it set out to solve. Go was not designed in a vacuum. It is the response of a group of people who spent their careers writing systems software, a response to their long-standing dissatisfaction with the mainstream languages of the time. Understanding this background gives a unified starting point for all the trade-offs the rest of this book examines, in the scheduler, the memory model, and generics.

1.2 An Overview of the Go Language

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

1.2 An Overview of the Go Language

This section builds a skeleton for the whole book. It is not a syntax manual; Go’s syntax is explained clearly in any introductory book, and repeating it would serve no purpose. What we want to do is first establish a bird’s-eye view of the whole: which layers make up Go, which distinctive design decisions it carries, and where in this book each of those decisions is developed. Once you have read this section, you can dive into any later chapter without losing your way.

1.3 Communicating Sequential Processes

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

1.3 Communicating Sequential Processes

This section comes with an online talk: YouTube, Google Slides.

The intellectual source of Go’s concurrency model is Communicating Sequential Processes (CSP), which Hoare proposed in CACM in 1978. This section traces that lineage from the perspective of the history of ideas, because it explains why goroutines and channels look the way they do today. The implementation details of channels and select (the ring buffer in hchan, the pairing of gopark and goready, the two-round locking in selectgo) are left for Chapter 10. Here we are concerned with “why CSP”, and with how that choice has shaped the appearance of Go programs.

2.1 The Plan 9 Assembly Language

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

2.1 The Plan 9 Assembly Language

Read the source of the Go runtime long enough, and sooner or later you run into code that looks like assembly yet not quite like any assembly you are familiar with. That is Go’s Plan 9 style assembly. We will keep returning to it as we dissect the scheduler, stack switching, and atomic operations: gogo, mcall, morestack, and asyncPreempt are all assembly routines. This section explains what it is, why it exists, and the few key concepts you need in order to read it. We do not aim to teach the reader to write Plan 9 assembly, which is the subject of another book; we aim to turn it into a reading vocabulary: when a later section mentions some assembly routine, the reader knows what kind of abstraction layer it lives in and what each symbol points to.

2.2 Stack Frames and Symbols in Assembly

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

2.2 Stack Frames and Symbols in Assembly

2.1 gave the pseudo-registers and addressing syntax of Plan 9 assembly, which is about “how to write one line of assembly”. This section raises our view to a complete routine: how a hand-written assembly function declares its own symbol with TEXT ·name(SB), how it states its stack frame size with $framesize-argsize, and what NOSPLIT means. We will match these conventions point by point against three real routines in the runtime (Cas, gogo, morestack), and once you finish reading, the assembly symbols in the chapters on the scheduler and stack management turn from gibberish into readable, on-the-spot operations.

2.3 Calling Convention and the Register ABI

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

2.3 Calling Convention and the Register ABI

The register names, stack-frame layout, and prologue code in this text use amd64 as the example. Other architectures (arm64, riscv64, and so on) share the same structure but differ in register names; you can cross-reference the “Architecture specifics” section of src/cmd/compile/abi-internal.

A single function call, at the machine level, has to answer a string of concrete questions: where do the arguments go, where does the return value go, who is responsible for saving which registers, how is the stack frame laid out, where is the return address pushed. Pinning down the answers to these questions is the calling convention, often also called the ABI (application binary interface). The ABI is not a piece of code but a contract: the code generated by the compiler, the hand-written Plan 9 assembly (2.1), and the low-level routines inside the runtime are written independently of one another, yet they have to mesh exactly at the moment of the call. Once the contract is fixed, all three sides arrange their data according to it, and none of them needs to know the internal details of the others.

2.4 Argument Passing and Stack Frame Layout

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

2.4 Argument Passing and Stack Frame Layout

2.3 laid out the division of labor between the two ABIs and the recursive algorithm for assigning arguments. That was the “rule”. This section grounds the rule in a concrete example: given a signature that mixes scalars and arrays, how exactly are the arguments arranged in the stack frame, why does a register argument still reserve a spill slot on the stack, and how does the stack growth check that nearly every function pays for in its prologue hitch a ride on preemption. Finally we return to the overall question of “why a custom ABI” and combine these two sections into a complete answer.

3.1 Starting from the `go` Command

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

3.1 Starting from the `go` Command

The life cycle of a Go program begins with running the go command. The go build, go test, and go run that readers type every day look like they merely “turn source into a binary,” but behind them hides a fact that is often misunderstood: go itself is not the compiler. It is a build orchestrator, responsible for breaking a single build into many individual steps, arranging their ordering and parallelism, and then invoking the real tools one by one: the compiler compile (3.2), the assembler asm, and the linker link (3.4). This section first makes this orchestration relationship clear, as it is the master outline for the sections that follow: once you understand how go decomposes a build into a graph and how it uses a content-addressed cache to avoid duplicate work, then turning to the details of compilation and linking gives you a frame to stand on.

3.2 The Go Compilation Pipeline

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

3.2 The Go Compilation Pipeline

3.1 explained that the real work behind go build is carried out by two programs, compile and link. This section zooms in on compile and traces the full journey from a single .go source file to a single .o object file: what each stage receives, what it produces, and why the work is cut up this way. This section is a panorama of the compilation pipeline. The inner workings of each stage (how the grammar is designed, what algorithm type checking uses, the optimization rules of SSA) are left to Chapter 15 to unfold one by one. Here we only string them into a single line and point out two threads that run through all of it.

3.3 Bootstrapping the Language

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

3.3 Bootstrapping the Language

One question sounds like a paradox: Go’s compiler, assembler, linker, and runtime are all written in Go today, so where did the first program capable of compiling Go come from? Without a Go compiler, how do you compile a Go compiler? This is bootstrapping. It is both the classic chicken-and-egg dilemma and a piece of engineering in the history of the Go toolchain that can be retold precisely. This section answers three things: how this egg was first hatched; how, after bootstrapping, the chain for building a new version of Go works, and why the demands it places on the bootstrap version keep rising year over year; and finally, why a language that “implements itself with itself” deserves to be taken seriously.

3.4 Module Linking

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

3.4 Module Linking

The compiler (3.2) turns each package into an object file, but an object file cannot run on its own. The object files still reference one another’s functions and variables, addresses are not yet fixed, and the runtime support is still missing. Assembling these fragments into a complete program that can be loaded and executed is the job of the linker (cmd/link, usually invoked by go build as go tool link). This section looks at what the linker does, and at a few choices Go makes around linking that together explain why a Go program is so often a self-contained file that “just runs once you copy it over.”

3.5 Bootstrapping a Go Program

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

3.5 Bootstrapping a Go Program

The main function the reader writes is not the program’s true first instruction. When the operating system hands control to a Go executable, what starts running is the runtime: it has to lay out the execution stack on the main thread, bind thread-local storage, measure the CPU core count and the physical page size of memory, wake up the memory allocator, the garbage collector, and the scheduler one by one, and only then create the goroutine that carries main and hand it to the scheduling loop to run. In other words, a Go binary carries within it a miniature operating system (1.2), one that starts itself up ahead of user code. This section walks the bootstrap chain from end to end, from the operating system’s entry symbol to the moment the first goroutine is scheduled, so we can see clearly what happens “before main.”

3.6 The Life and Death of the Main Goroutine

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

3.6 The Life and Death of the Main Goroutine

In 3.5, once schedinit has assembled the runtime’s foundations, it does not call runtime.main directly. Instead it pushes that function’s entry address onto the stack, hands it to newproc to fabricate the first Goroutine, and then lets mstart start the scheduling loop and pick this Goroutine out to run. The details of scheduling are left for 9 Scheduler. This section trains the camera on a single moment: the first Goroutine is already running, and it is about to execute runtime.main.

4.1 The Runtime Type System

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

4.1 The Runtime Type System

Go is a statically typed language, and type checking happens at compile time. Yet Go still keeps a substantial amount of runtime type information (RTTI), and it is precisely this that supports interfaces (4.2), type assertions, type switches, reflection, and the garbage collector’s precise identification of pointers. This section answers a seemingly simple question: of the type machinery that exists at compile time, what survives into the runtime, in what form is it kept, and what capabilities does it underpin. Once you understand the small structure called the type descriptor in this section, the interface (4.2), reflection, and precise GC (13) all gain a common footing.

4.2 Interfaces

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

4.2 Interfaces

Interfaces are the soul of Go’s type system. They decouple behavior from implementation, and they do it in an unusual way: structural, implicit satisfaction, unlike most mainstream languages. This section looks at how interfaces are represented at runtime, how methods are dispatched dynamically, how type assertions are realized, and where this design sits within the broader lineage of polymorphism. Following the approach of the previous sections, the structs given below are trimmed-down sketches: they keep only the fields relevant to the design, with comments explaining why each one exists. For the full definitions, compare against runtime/runtime2.go, internal/abi/iface.go, and runtime/iface.go.

4.3 Type Aliases

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

4.3 Type Aliases

type A = B (a type alias) and type A B (defining a new type) differ by a single equals sign, yet the semantics are fundamentally different. The former merely gives a new name to an existing type; the latter creates a brand-new type with its own independent identity. The distinction looks minor, but it pulls on the whole set of rules governing type equality, method sets, and assignability (4.1), and it also pulls on a question Go has always cared about: when a body of code is no longer maintained by its original author yet still has to evolve without breaking compatibility, how should a type migrate from one package to another. This section first makes the semantics of aliases and defined types clear, then explains why aliases were introduced in Go 1.9, and finally looks at the generic capability they gained in Go 1.24.

5.1 Arrays and Slices

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

5.1 Arrays and Slices

Arrays and slices are the two most basic sequence types in Go. They look similar, yet their memory models differ, and grasping this one point explains in a single stroke all the “surprises” of append and the traps of slice aliasing. Both share a single theme: a small header describing a stretch of contiguous backing memory. The differences lie entirely in what the header holds and who owns that memory. This section first lays out the layout clearly, then starts from the classic abstraction of the “dynamic array” to see how Go’s append achieves amortized $O(1)$ , and finally lands on aliasing and cross-language comparison, the corners we run into day to day. Strings, though they share the same origin as slices, are immutable and form a category of their own; we leave them to 5.2 for dedicated discussion.

5.2 Strings and Zero-Copy Conversion

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

5.2 Strings and Zero-Copy Conversion

Strings share their origin with slices: in the runtime both are “a header plus memory living elsewhere” (for the layout, see 5.1.1). But a string is read-only and immutable, which makes it its own category. Immutability buys us sharing and copy-free use, and it brings one direct cost: converting between string and []byte copies the bytes by default. This section opens up that copy, looks at the cases where the compiler can elide it, then turns to the manual zero-copy tools Go 1.20 provides and the safety contract that comes with them.

5.3 Hash Tables: Principles and Security

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

5.3 Hash Tables: Principles and Security

Go’s map underwent a rare, complete rewrite in 2024 alongside Go 1.24, moving from the classic bucketed hash table it had used for fourteen years to an implementation based on Swiss Tables. This section first clarifies the general principles of hash tables and the attack-and-defense around them, leaving the full story of the rewrite to 5.4.

map is one of only two generic containers Go provides (the other being slice). It is implemented by the runtime with the compiler assisting in layout, and at its core it is a hash table. When the reader writes m[k], the compiler translates it into calls to the runtime.mapaccess and runtime.mapassign family of functions; the real storage, lookup, and growth all happen inside the internal/runtime/maps package. This section first lays out the general principles of hash tables and the attack-and-defense around them, to ground the next section where we drop down to Go’s own two generations of implementation (the classic bucketed design from 1.0 through 1.23, and the Swiss Table design from 1.24 onward). Only by understanding the trade-offs here can we see why the latter was worth a rewrite that cut to the bone.

5.4 Swiss Table and the Go 1.24 Implementation

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

5.4 Swiss Table and the Go 1.24 Implementation

5.3 laid out the general principles of hash tables and the attack-and-defense around them: the two routes for handling collisions, and the defense against hash flooding. This section comes down to Go’s own two generations of implementation. We first open up Swiss Table, a modern open-addressing design, then look at how Go 1.24 brought it to ground and what it replaced in the process, then derive from the implementation two language rules that follow from it, and finally place Go within the larger picture of the various hash tables out there.

6.1 Function Calls

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

6.1 Function Calls

Functions are first-class citizens in Go: they can be assigned, passed, returned, and they can capture outer variables to become closures. Behind this lie two implementation questions: how a function value (a closure) is represented in memory, and how a single function call passes arguments and returns values at the lowest level. The latter also hides a quiet but sweeping change introduced in Go 1.17: passing arguments in registers instead of on the stack. This section explains both thoroughly, and at the seam between them points out a key fact, the very fact that welds “what a closure is” and “how a call happens” into one and the same thing.

6.2 Deferred Statements

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

6.2 Deferred Statements

The deferred statement defer did not exist in the earliest Go designs; it was added later as a separate feature, with Robert Griesemer writing the language specification [Griesemer, 2009] and Ken Thompson producing the earliest implementation [Thompson, 2009]. Its semantics read very short: a defer-red call runs when the enclosing function returns, when a panic occurs, or when runtime.Goexit is called. Intuitively this looks like a purely compile-time feature, similar to C++’s RAII (automatic destruction when leaving a scope); the compiler would seem to only need to “move” the deferred call to the end of the function, with no runtime cost.

6.3 The panic and recover Builtins

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

6.3 The panic and recover Builtins

defer (6.2) has already settled the question of “what to do when a function exits,” leaving open the question of “what happens when a function is interrupted abnormally.” The pair of builtins panic and recover answers exactly this: the former interrupts the current normal control flow and begins unwinding up the call stack, while the latter catches it mid-unwind. This section first makes their semantics clear, then comes down to the go1.26 runtime implementation of gopanic and gorecover, and finally returns to a more pressing question: what panic should really be taken to be, and why Go did not make it into an exception mechanism like the one in C++ or Java.

7.1 The Evolution of the Problem

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

7.1 The Evolution of the Problem

In 6.3 we already drew the dividing line: how to handle errors is one of the fundamental choices in language design. The exception camp (C++, Java, Python) uses try/catch to pull the error path out of the normal logic, keeping the main line clean, at the cost of making the error path implicit, capable of being thrown from any call site. The value camp (Go, Rust, and C’s return-code tradition) passes errors explicitly as ordinary return values: verbose, but every error path is spelled out in black and white with nowhere to hide. Go chose the value camp, reserving a lightweight panic/recover only for “true exceptions.” What this section is about is what happened after that choice landed: how the proposition of “errors as values” itself evolved, from a string you could only print into a tree that a program can interrogate layer by layer, asking “are you really that error?”

7.2 Inspecting Error Values

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

7.2 Inspecting Error Values

Once an error propagates up a call chain, the code that handles it and the code that produced it are often separated by many layers. This raises a plain but thorny question: given an error that has been passed up through layer after layer, how does the caller decide “is this actually some particular error”, and how does it retrieve the specific error value that originally carried the context? This section answers exactly that, along with the conventions Go has set down for it in the errors package.

7.3 Error Format and Context

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

7.3 Error Format and Context

A good error does not merely say “something went wrong.” It tells a person what was being done, on account of what, and what went wrong. The evolution of the problem (7.1) and value inspection (7.2) gave us the mechanisms for propagating and examining errors. This section discusses the engineering practice that sits on top of those mechanisms: how the text of an error should be written, how context accumulates layer by layer along the call chain, and how stack traces and structured logs can be added on demand when human-written words are not enough. Running through all of it is one overall tendency Go has regarding error information: human-written semantic context is preferable to machine-collected stack traces.

7.4 Error Semantics

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

7.4 Error Semantics

7.2 and 7.3 stood on the caller’s side of an error and worked out how, once you hold an error, to inspect it along the chain and how to layer context onto it. This section turns the viewpoint to the other side, standing with the library author and asking a question that comes before inspection: when a package wants to expose a failure to the outside world, what form should it give that error? Should it export a comparable value, export a type with fields, or export nothing at all?

7.5 The Future of Error Handling

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

7.5 The Future of Error Handling

In the preceding sections we saw the plainness of the error interface, %w wrapping, and the inspection of error chains. By this point the reader probably carries an unspoken question: those three lines of if err != nil boilerplate, spread year after year across every Go program, is there really no way to get rid of them? The question is not a lonely one. From the go2 draft of 2018 to a single conclusion in 2025, the Go team weighed it back and forth for seven years, proposing several syntaxes such as check/handle, try, and ?, and then withdrawing them one by one. This section places that path of failed syntax side by side with another, quietly successful path of library evolution, and lays out the judgment the Go team finally arrived at: for the foreseeable future, error handling will not receive any dedicated syntax.

8.1 The Evolution of Generics Design

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

8.1 The Evolution of Generics Design

Generics is the feature Go waited longest for, argued about most fiercely, and that best embodies its design philosophy. From the open-source release in 2009 to its arrival in Go 1.18 in 2022, the thirteen years of hesitation and the eventual choices are themselves a lesson in language design. This section answers three questions: why Go held off on generics for so long, how it finally added them, and how they are implemented underneath. The last question matters most, because Go’s implementation copies no existing precedent and instead takes a distinctive middle road, and it is that road that is Go’s real answer to the thirteen-year problem. How the design itself evolved along the way (contracts, type sets, several rounds of syntax proposals) is left to 8.4; this section takes only the skeleton.

8.2 Contract-Based Generics

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

8.2 Contract-Based Generics

This section has a companion online talk: on YouTube, Google Slides deck. The deck was recorded in 2019, while the contracts proposal was still under discussion, and it corroborates this section.

8.1 glossed over the evolution “contracts came first, then a turn toward interfaces as constraints” in a single sentence. This section unfolds that sentence: what contracts actually looked like, how much expressive power they had, and why they were ultimately abandoned. This rejected design is not historical waste; it explains where today’s [T Ordered] syntax came from, and it illustrates a move that recurs throughout Go’s design: first produce a highly expressive but somewhat complex scheme, then turn back and ask “can this be expressed with concepts we already have”, forcing complexity to earn its right to exist.

8.3 Type-Checking Techniques

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

8.3 Type-Checking Techniques

Generics pose a far harder problem to the type checker than before. The old judgment had only one shape: “is this value of this type?” With type parameters, the checker now has to answer three new questions: whether a type argument satisfies a constraint, whether an operation like a + b is valid on an unknown type, and what that unwritten T actually is when you call Max(3, 5). These three concerns correspond to the three topics of this section: type sets, core types, and type inference. They are where the design from 8.1 lands as concrete compile-time technique, and they are also a prelude to the front end of 15 The Compiler.

8.4 The Future of Generics

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

8.4 The Future of Generics

Generics landed in 1.18 and more than four years have passed. This section no longer dwells on speculation about “what might be.” Instead it looks back and takes inventory: which expectations were met, which were deliberately shelved, and where the tension that runs through it all (the cost of abstraction) stands today. The author once gave a public talk on Go 2 generics in earlier years (YouTube, slides). Most of those predictions can now be checked against reality, and this section accounts for them along the way.

9.1 The Scheduling Problem and the GMP Model

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

9.1 The Scheduling Problem and the GMP Model

Write go f() and a goroutine starts running. Behind that one line sits the most intricate machine in the Go runtime: the scheduler. It has to answer a question that is not at all simple: how can tens of thousands of goroutines take turns on a small handful of CPU cores, running fast while letting the user barely notice it is there. This section first lays out the problem the scheduler must solve, its overall skeleton, and its place in the larger family of concurrent runtimes. Later sections then go deep into each component.

9.2 Work-Stealing Scheduling

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

9.2 Work-Stealing Scheduling

9.1 left us a question: each P has its own local queue, so work is bound to be distributed unevenly. Some Ps are overwhelmed while others sit idle. How to spread the load without introducing a central bottleneck is the core difficulty of concurrent scheduling. Go’s answer is a design with thirty years of theory behind it, one that recurs throughout the industry: work stealing.

This section goes a bit deeper than the rest. We first make clear what Go does, then trace back to the scheduling theory behind it (why it is “provably good”), then look across its different incarnations in systems such as Cilk, Java, and Rust, and finally stop at the questions that remain open.

9.3 The MPG Model and the Units of Concurrent Scheduling

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

9.3 The MPG Model and the Units of Concurrent Scheduling

The first question a scheduler must answer is not “how to schedule” but “what to schedule.” Go calls the thing being scheduled a goroutine, and carries it on a triple of M, P, and G. Before we get our hands on the scheduling algorithm (from 9.4 onward), this section settles these three scheduling units: what a goroutine really is within the lineage of computer science, how its running context is encoded, why scheduling itself has to happen on a special g0, what states a goroutine passes through over its life, and how the worker thread M that carries it is parked and unparked. Once these few things are clear, the scheduling algorithms that follow are just “moving G around among these units.”

9.4 The Scheduling Loop

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

9.4 The Scheduling Loop

The previous sections laid out the materials: we know what G, M, and P are (9.3), and we know how an M finds work (9.2). This section actually sets them spinning, watching how the scheduling loop ceaselessly picks and runs goroutines on a single thread, and how it strikes a balance between “letting a single goroutine run a little longer” (throughput and locality) and “not letting any goroutine starve” (fairness).

9.5 Thread Management

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

9.5 Thread Management

9.1 laid down the three-layer GMP structure: G is the user-level unit of execution, P is the scheduling permit and the carrier of local resources, and M is the leg actually borrowed from the operating system. The previous sections dwelt mostly on G and P; this section turns its attention to M, and answers several questions we have kept deferring: what M actually is, where it comes from, why GOMAXPROCS caps P while the thread count is often larger, why a single blocking system call does not drag down the other G alongside it, and what price the runtime pays when a user wants to pin a goroutine to a specific thread (LockOSThread).

9.6 Signal Handling

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

9.6 Signal Handling

Operating system signals are asynchronous and low-level: a signal may interrupt any thread at any moment, and what the signal handler is allowed to do is severely constrained. What Go users want, on the other hand, is usually to wire a channel to SIGINT with signal.Notify and shut down gracefully when it arrives. What the runtime has to do is build a bridge between these two: turn a treacherous asynchronous signal into an event a goroutine can consume in peace. Every design choice on this bridge is governed by one hard constraint: what can be done inside a signal context. Once you understand this constraint, the rest of this section’s mechanics are merely its corollaries.

9.7 Cooperation and Preemption

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

9.7 Cooperation and Preemption

In 9.5 The Scheduling Loop we left an open question: if some G runs for too long, how can other G’s still get scheduled? The answer cannot avoid an old pair of concepts from scheduling theory, cooperative versus preemptive. Cooperative scheduling relies on the scheduled party voluntarily yielding; preemptive scheduling relies on the scheduler interrupting the scheduled party from the outside.

The Go runtime has nothing like the hardware interrupt capability of an operating system kernel. The work-stealing scheduler (9.2) is essentially first-come-first-served cooperative scheduling. How it can still forcibly interrupt a G that refuses to yield, without sacrificing this premise, is the design this section sets out to make clear. The thread starts from a theoretical question: by what right can the runtime not stop a goroutine at an arbitrary instruction?

9.8 System Monitoring

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

9.8 System Monitoring

The scheduler’s ordinary path was laid out in 9.4 The Scheduling Loop: one M binds to one P, takes a Goroutine off the queue, runs it, then takes the next. This path rests on one premise, that it gets a chance to run at all. Yet once all the Ps are mired in long system calls, or some Goroutine spins forever and holds a P hostage, ordinary scheduling seizes up. No one takes the P back, and no one polls the network. Put differently, cooperative logic that runs on a P cannot deal with the situation where “the P itself cannot move.”

9.9 The Network Poller

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

9.9 The Network Poller

Source facts verified against src/runtime/netpoll.go and its per-platform implementations (netpoll_epoll.go, netpoll_kqueue.go, and so on) and src/internal/poll/fd_unix.go.

Go’s network code looks blocking: conn.Read simply “sits” there waiting for data. But if it truly blocked the operating system thread it runs on, then ten thousand goroutines waiting on the network would tie up ten thousand threads, and the M:N model that 9.1 worked so hard to build would collapse in an instant. What lets the blocking style still scale is the network poller (netpoller). Behind it lies a long history about “how to tend a vast number of connections with a handful of threads.” This section first lays out that history and the design axes behind it, then looks at how Go hides a mature event mechanism inside the runtime so that you write synchronous code and run event-driven I/O.

9.10 Timers

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

9.10 Timers

time.Sleep, time.After, time.Timer, time.Ticker, and even SetDeadline on network reads and writes all rest on the same timer machinery. It has to answer a question that looks simple but is in fact subtle, a question about data structures: when thousands of timers exist at once, how do we efficiently know “who should be woken next, and when,” without burning a thread to do it. This section starts from that abstract problem, makes the trade-offs of the various solutions clear, and then lands on Go’s choice and how it evolved.

9.11 NUMA Awareness and the Future of the Scheduler

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

9.11 NUMA Awareness and the Future of the Scheduler

The scheduler described in the preceding sections rests on an assumption that was never spelled out: every M reaches memory equally fast, and moving a G between any two Ps costs the same. On a laptop or a single-socket server, that assumption is nearly true. But once you put the program on a large multi-socket server it begins to break, and the more cores there are, the wider the gap. This section is about that crack: where it comes from, why the Go scheduler has looked past it for so long, a NUMA-aware design that was carefully thought through yet never shipped, and how users today work around it.

10.1 Channels and the Engineering of CSP

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

10.1 Channels and the Engineering of CSP

A recorded talk accompanies this section: online on YouTube, Google Slides deck.

CSP gives Go a claim: processes do not share state, they coordinate solely by passing messages (1.3). This section is concerned with a different question: for an engineering language to make this claim real, what shape must “communication” take so that an ordinary programmer can reach for it and get it right. Go’s answer is the channel, a first-class primitive that is at once synchronization and communication. We begin by laying out its model at the surface of the language, its type, its send and receive syntax, the two semantics of buffered versus unbuffered, directional restriction, and nil behavior, building the intuition that the later sections will need as they descend into the runtime implementation (10.2–10.7).

10.2 hchan: The Internal Structure of a Channel

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

10.2 hchan: The Internal Structure of a Channel

10.1 placed channels within the language from the angle of CSP: a channel is an explicit message conduit that fuses “communication” and “synchronization” into one. This section takes it apart. At runtime a channel is a struct called hchan, and its whole secret amounts to a single lock, a ring of buffered storage, plus two wait queues. The structure is small, yet every field exists for a specific design reason. Once you understand these few pieces, the entire logic of sending, receiving, and select that follows (10.3–10.6 The Memory Model and the Move Toward Lock-Free) is just “moving data, parking and waking goroutines on top of this one picture.”

10.3 Send, Receive, and Direct Handoff

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

10.3 Send, Receive, and Direct Handoff

10.2 laid out the skeleton of hchan: a lock, a ring buffer buf, plus a sender queue sendq and a receiver queue recvq. This section brings the skeleton to life and answers what actually happens inside the runtime during a single ch <- v and a single v := <-ch. Once you understand this send/receive path, the two most frequently asked properties of a channel, why an unbuffered channel is a single rendezvous, and why for it a receive happens before the corresponding send completes (11.9), both come down to the same mechanism: direct send / receive.

10.4 The Semantics of Closing

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

10.4 The Semantics of Closing

In the previous sections, both sending and receiving were “one-to-one” rendezvous: one send pairs with one receive, and the surplus side blocks and waits. Closing is the only “one-to-many” operation on a channel. close(ch) is issued by a single Goroutine, yet in an instant it wakes every receiver currently blocked on the channel and makes every blocked sender panic on the spot. This ability to “broadcast once and wake everyone” turns closing from a seemingly minor cleanup action into the most commonly used cancellation and wind-down mechanism in Go concurrency. The done channel pattern and context cancellation (11.8) both trace their roots back here.

10.5 The Implementation of select

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

10.5 The Implementation of select

The previous sections covered send and receive on a single channel (10.3) in full. In practice, though, a Goroutine rarely watches just one channel: it wants to react to whichever operation becomes ready first among several sends and receives, and it also wants to avoid blocking when none of them is ready. select exists exactly for this. Its semantics look simple, yet the implementation has to solve two thorny problems at once: how to choose fairly when several branches are ready, and how to avoid deadlock when locking several channels to run a single select. These two concerns shape the entire structure of selectgo, and this section is built around them.

10.6 The Memory Model and the Lock-Free Evolution

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

10.6 The Memory Model and the Lock-Free Evolution

The previous sections took the channel apart down to its parts: the direct handoff in 10.3 lets the sending and receiving ends pass a value directly, bypassing the ring buffer, and select in 10.5 makes a random choice among several ready branches. These mechanisms explain how a channel “runs”. This section answers two higher-level questions: what visibility guarantee a channel offers to a concurrent program, and an engineering mystery that is often raised, why a channel is still “a lock plus a queue” to this day rather than the supposedly faster lock-free structure. The former reconnects the channel to the memory model in 11.9; the latter is a real trade-off about “how correctness and maintainability win out over peak performance”.

10.7 Engineering Practice and Cross-Language Comparison

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

10.7 Engineering Practice and Cross-Language Comparison

The previous sections took the internal structure of a channel, the send and receive paths, and the implementation of select all the way down. Once we understand the mechanism, a harder and more engineering-flavored question follows: when should we use a channel, and when should we not. Go’s slogan, “Do not communicate by sharing memory; instead, share memory by communicating,” is easily read as “any shared state should go through a channel,” but that is not what its author meant. This section reduces that slogan to an actionable rule of thumb, sets it against the lighter tools in the chapter on synchronization primitives (Chapter 11), and then places Go’s choice within the lineage of the CSP family, so we can understand its specific coordinates in the design space.

11.1 Shared-Memory Synchronization Patterns

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

11.1 Shared-Memory Synchronization Patterns

The fact that programs can be constructed from simpler basic primitives is a strong guarantee: what these primitives contain stays logically consistent with the rest of the programming language. – C. A. R. Hoare

The whole difficulty of concurrent programming can be distilled into a single sentence: multiple units of execution must cooperate over the same shared state, and the order in which each of them makes progress cannot be predicted. How to make that cooperation both correct and efficient has, over more than half a century, split into two great traditions. This chapter is about one of them, shared memory. Before we take apart the concrete primitives in Go’s standard library sync and sync/atomic, this section first lays the two traditions side by side to tell them apart, explains why they are dual to each other, and then states where Go stands between them. Once you understand this layer of trade-offs, the sections from 11.2 through 11.9 are no longer isolated APIs but the same design philosophy landing on different scenarios.

11.2 Mutex

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

11.2 Mutex

sync.Mutex is the most basic synchronization primitive: it lets only one goroutine enter the critical section at a time. Beneath that plain interface, it keeps weighing two goals that pull against each other, throughput (hand the lock to someone as quickly as possible, do not let the CPU sit idle) and fairness (do not let some unlucky waiter wait in line forever). The two cannot both be maxed out: handing the lock off in strict arrival order is the fairest, but pays a context switch on every handoff; letting a just-woken waiter compete freely with whoever is running is the fastest, but can leave some waiter losing out again and again. This section first lays out the theory and the hardware foundations of the old problem of mutual exclusion, then looks at how Go’s mutex walks this tightrope.

11.3 Atomic Operations

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

11.3 Atomic Operations

sync/atomic is the layer of Go’s synchronization primitives that sits closest to the hardware. Higher-level tools such as the mutex (11.1) and channels (8) are all built on top of atomic operations internally. It provides “indivisible” reads, writes, and read-modify-writes: an atomic operation either happens in full or not at all, and no other goroutine ever sees it half-finished. But the meaning of atomic operations goes far beyond “no tearing.” It is the foundation of lock-free programming, and behind lock-free programming lies a profound theory about “which primitives can do what.” That theory is what this section really wants to make clear.

11.4 Condition Variables

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

11.4 Condition Variables

The mutex (11.2) answers the question of “who may enter the critical section.” A condition variable answers a different one: “a Goroutine has already entered the critical section, but finds it cannot do its work yet; how does it wait until the moment it can, while yielding the critical section to others.” The producer and consumer is the most common example. When the queue is full, the producer can neither write nor keep spinning while holding the lock, otherwise the consumer can never acquire the lock to free up space, and both sides deadlock together. The condition variable sync.Cond offers this way out: let the producer “sleep with the lock,” atomically hand off the lock and block, and once the consumer frees up space, wake it back up, with the lock back in its hands on waking.

11.5 Wait Groups

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

11.5 Wait Groups

The mutex (11.2) and the condition variable (11.4) from the previous sections solve the problem of “multiple Goroutines contending for the same shared state.” This section turns to sync.WaitGroup, which solves a different class of problem: one Goroutine spawns several subtasks, then waits for all of them to finish before continuing. The former is contention, the latter is rendezvous. This is one of the most common structures in concurrent programming, called fork-join, and WaitGroup is exactly the Go standard library’s answer to it.

11.6 Object Pool

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

11.6 Object Pool

Allocating and then discarding the same kind of temporary object over and over puts heavy pressure on the garbage collector (13). sync.Pool offers a way out: stash a used object and reuse it next time instead of allocating fresh every time. Its typical use is for temporary objects like buffers and serializers that are “discarded after one use, yet needed again and again”.

1
2
3
4
5
6


var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}

b := bufPool.Get().(*bytes.Buffer)
b.Reset() // the object you get back may be dirty, so reset it first
// ... use b ...
bufPool.Put(b) // put it back when done, for others to reuse

New is the only field the user needs to supply: when the pool has no object to hand out, it falls back to New to make one. So what Get returns is either an old object someone just put back, or a new one freshly made by New, and the caller has no way, and no need, to tell the two apart. This section first covers the ancient idea of reusing objects that the pool rests on, then unpacks the three layers it builds for concurrency and GC: per-P sharding, the victim cache, and cooperation with the runtime’s GC.

11.7 Concurrency-Safe Hash Table

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

11.7 Concurrency-Safe Hash Table

sync.Map went through a complete internal rewrite in Go 1.24: the original read/dirty two-map design was replaced by a concurrent hash-trie. This section first makes the origin of each of these two generations of design clear, then places them back into the solution lineage of concurrent hash tables.

The language’s built-in map is not concurrency-safe. When multiple goroutines read and write the same map simultaneously without synchronization, the runtime actively detects the concurrent access and terminates the process with fatal error: concurrent map read and map write (5.2 introduced this detection mechanism; it is unrecoverable, and recover cannot intercept it). For services with availability requirements, this is a design question that must be answered head-on: when multiple goroutines need to share one table, what structure should be used.

11.8 Context

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

11.8 Context

A request entering a server seldom runs to completion inside a single goroutine. It fans out into a tree of goroutines: one queries the database, one calls a downstream RPC, one reads the cache, and each of these spawns smaller units of work in turn. Once the originator of the request no longer needs the result, say the client has disconnected, or the upstream has already timed out, all the work still running across that tree becomes pure waste, holding connections, locks, and memory while no one will ever read what it produces. The problem then becomes: how do we propagate the signal “stop here” from the root of the tree out to every leaf, so each of them can stop on its own.

11.9 Memory Consistency Models

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

11.9 Memory Consistency Models

Go’s memory model went through an important revision in 2022 with Go 1.19. After laying out the current model, this section devotes space to the background of that revision (see 11.9.8).

The reader may have noticed that in the earlier discussion of the Go runtime and compiler we kept steering clear of one topic: Go’s memory model. The avoidance was not without reason. To explain it properly requires groundwork in concurrency, synchronization primitives, and even the hardware layer, and only now is that groundwork in place. As the close of this chapter, and as the book’s summary of Go’s synchronization primitives and patterns, we take up the topic here and answer the question still unresolved in the reader’s mind: when two Goroutines read and write the same variable at once, under what conditions is one side’s write guaranteed to be seen by the other.

12.1 Design Principles

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

12.1 Design Principles

By now we have seen how a Go program starts up, and how the scheduler spreads goroutines across operating-system threads for execution. The single thing that scheduled code does most often is request memory: every new, every local variable that escapes to the heap, every slice growth, all funnel into the same entry point, runtime.mallocgc. This chapter is about the allocator behind that entry point. This section does not yet touch its parts; it answers a question that comes first: what mutually pulling goals must a memory allocator built for Go satisfy, and on which few judgments does it settle them? Once you understand these trade-offs, the structures and paths in the following sections (12.2–12.6) will all have a clear origin.

12.2 Components

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

12.2 Components

12.1 described the allocator as a layered structure that is “lock-free on the fast path, locked on the slow path.” This section names and locates the few core components of that structure, and grounds them in their actual form in go1.26: what state each component carries, why it is designed the way it is, and how they chain together into a restocking pipeline. Once you have understood these few things, the later allocation paths (12.4–12.6) are just “a walk across this same picture.”

12.3 Initialization

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

12.3 Initialization

12.2 broke the allocator down into a few parts: mcache, mcentral, mheap, and arena. But that was a static picture. These parts do not fall into place on their own; they must be set up once, at the very start of the program. This section answers the question: when main has not yet run and the first new has not yet happened, what infrastructure does the runtime lay down for the allocator.

12.4 Large Object Allocation

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

12.4 Large Object Allocation

The allocation hierarchy of 12.2 was built for objects that are “small and frequent”: a per-P mcache, a mcentral shared by size class, and a global mheap. These three cache layers collapse the vast majority of allocations into a handful of lock-free bit operations. But this delicate machine carries an implicit premise, that the object is small enough to fit into a size class. Once an object exceeds maxSmallSize (32768 bytes in go1.26, that is 32KB), it no longer fits into any size class slot, and the whole replenishment chain loses its meaning for it.

12.5 Small Object Allocation

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

12.5 Small Object Allocation

Small objects are those whose size falls between 16B and 32KB (in go1.26, maxSmallSize = 32768). They are the most common kind of allocation in a Go program: a struct, the backing array of a modest slice, the result of a string concatenation, the vast majority land in this range. The path the allocator designs for them is the main stage of the mcache → mcentral → mheap hierarchy from 12.2, and it is where the whole allocator’s “lock-free fast path” design (12.1) makes good on its performance promise.

12.6 Tiny Object Allocation

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

12.6 Tiny Object Allocation

The previous two sections walked through the two ends of the allocator. Large objects (12.4) bypass the cache and ask the mheap for memory by the page directly; small objects (12.5) pull an equal-sized slot from the per-P mcache according to their size class. This section fills in the last and least conspicuous category of object, the tiny object: those smaller than 16 bytes and free of pointers. They are extremely numerous and individually tiny, so if each were also given a slot by size class, the waste would be astonishing. Go sets up a dedicated path for them, packing multiple tiny objects into the same block, and trades one simple “bump pointer” technique for sizable memory savings.

12.7 The Page Allocator

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

12.7 The Page Allocator

Beneath mheap (12.2), the component that answers “which pages are free, which are in use” is the page allocator. It is the foundation of the entire allocator: when an mcentral runs out of spans it asks mheap for new pages, large objects (12.4) are requested directly by page, and every page a span occupies is ultimately carved out from here. The page allocator must also return pages that have stayed idle for a long time back to the operating system. These two responsibilities, one tied to the speed of allocation and the other to the resident memory of the process, are exactly the most enduring tension in Go’s memory system.

12.8 Memory Statistics

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

12.8 Memory Statistics

The allocator keeps books while it works. Every time it wholesales a stretch of address space from the operating system, carves out a span, or allocates or sweeps an object, the runtime accumulates the corresponding count into a set of global variables (runtime.memstats). These books are not a statistical report compiled after the fact; they are a running ledger written down in passing during allocation and reclamation. They serve two ends. Outwardly, they let users and monitoring systems see the memory shape of the process. Inwardly, both the GC pacer (13.3) and the soft memory limit GOMEMLIMIT (12.7) must read these books to decide “at what heap size should the next round of reclamation be triggered.” In other words, the bookkeeping closes a feedback loop: allocation produces data, data drives decisions, and decisions in turn constrain allocation.

12.9 Past, Present, and Future

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

12.9 Past, Present, and Future

The allocator did not arrive fully formed. It has been polished over and over as Go evolved. Tracing this line of evolution makes clear which trade-offs the current design grew out of, and gives a glimpse of where it is headed. One judgment worth keeping in mind first: nearly every major change to the allocator was not made to make “allocation itself faster,” but to re-place a stone in the three-way game among allocation speed, memory footprint, and cooperation with the garbage collector. Once this main thread is read, the several rewrites below stop looking like isolated version trivia and become instead the same engineering problem being solved again and again.

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?

14.1 Design of Contiguous Stacks

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

14.1 Design of Contiguous Stacks

Every goroutine carries an execution stack. It holds the local variables, arguments, and return addresses of function calls, and it is the physical medium that lets a program be “currently executing”. In the C programs the reader is familiar with, this stack is provided by the operating system thread, its size fixed once at thread creation (ulimit -s defaults are often 8MB) and unchanged thereafter. Go took a different road: a goroutine’s stack is not a thread stack but a segment of memory that the runtime allocates on the heap, manages itself, and can resize, starting at just 2KB.

14.2 Stack Allocation and Caching

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

14.2 Stack Allocation and Caching

14.1 located the execution stack as a contiguous range of memory [lo, hi): it is managed by the runtime and ultimately lives on the heap, so the moment a Goroutine starts, someone has to carve out this range of addresses for it. The questions follow immediately: who carves it? how large? and once Goroutines are created and destroyed over and over, if these two- or three-kilobyte chunks of memory had to be requested directly from the operating system or the global heap every time, the cost of locks and system calls would crush the scheduler at once.

14.3 Stack Growth

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

14.3 Stack Growth

14.1 laid out the reasons Go chose contiguous stacks: a stack starts at just 2KB, and on overflow it swaps in a new stack twice as large and copies the entire old stack across. This section answers only one of the questions involved: how the runtime knows, at the “right moment,” that a stack is about to fill up, and how it hands control all the way over to the code responsible for the growth. The details of the stack copy itself are left to 14.4.

14.4 Stack Copying and Pointer Adjustment

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

14.4 Stack Copying and Pointer Adjustment

The cost of contiguous stacks is concentrated in one place: when a goroutine’s stack overflows, the runtime allocates a new stack twice the size, moves the entire old stack over, and then frees the old stack. The moving step looks like nothing more than a single memmove, copying the bytes of [old.lo, old.hi) into [new.lo, new.hi). If it really were just copying bytes, a problem would arise: variables on the stack may hold pointers into the stack itself, for example a local variable that has taken the address of another local. After the bytes are moved verbatim to a new address, the values of these pointers are unchanged, still pointing at locations in the old stack, and the old stack is about to be reclaimed. The moment the copy finishes, they become dangling pointers.

14.5 Stack Shrinking and Evolution

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

14.5 Stack Shrinking and Evolution

14.4 was about the stack “growing up”: when a function prologue finds the stack nearly exhausted, the runtime copies the whole stack onto a larger block of memory, and the stack pointer shifts along with it. This is a one-directional force driven by execution itself, and it only ever makes the stack larger. Yet a goroutine’s stack depth is not monotonic. A recursion may descend very deep, then return layer by layer back to a shallow point; the stack it actually needs has long since shrunk back, but the large stack expanded for that deep recursion is still held in its name. With growth but no return, every goroutine’s stack would eventually settle at its historical deepest point. For a program that may hold millions of goroutines, this bill is unbearable.

15.1 Lexing and Grammar

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

15.1 Lexing and Grammar

The first stop of compilation is turning source text into a structured abstract syntax tree (AST). This takes lexical analysis (slicing a character stream into tokens) and syntactic analysis (organizing tokens into a tree according to the grammar). 3.2 surveyed the whole pipeline from above; this section looks only at its front end, and at why Go’s grammar was designed to be so “easy to parse”.

The package that carries out these two steps is a self-contained part of the compiler, cmd/compile/internal/syntax. It is built from two instruments: the scanner reads characters and emits a token stream; the parser consumes tokens in a recursive descent fashion and builds the syntax tree. The package’s own comments even note with some pride that several of its files, scanner.go, source.go, and tokens.go, do not depend on the rest of the compiler and can be compiled on their own into a standalone library. The reason lexing and grammar can be carved out this cleanly lies in the simplicity of the Go grammar itself.

15.2 Intermediate Representation

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

15.2 Intermediate Representation

15.1 turned source code into a syntax tree (AST). The AST faithfully records the structure the programmer wrote down: variables, scopes, the nesting of expressions. But the moment we want to optimize, this structure sits too “high.” Consider the most unremarkable line, x = x + 1: in the AST, the x on the left and the x on the right are the same name, and if the compiler wants to know “which assignment produced the value of the x used here,” it has to repeatedly perform scope lookups and data-flow analysis. Names get shadowed, scopes nest, an assignment wipes out the old value, and all of this makes “where a value comes from and where it goes,” which ought to be the most basic thing, murky. What the optimizer wants most is exactly to lay the data flow out in the open.

15.3 The Optimizer

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

15.3 The Optimizer

15.2 lowered the front end’s syntax tree down to the SSA intermediate representation and explained why SSA’s “each variable is assigned exactly once” makes the optimization passes both accurate and fast to write. This section continues from there: on top of this representation, what optimizations does the compiler actually run, and why precisely these few.

To read the Go optimizer well, we first have to read its disposition. Faced with the same task of turning a high-level language into machine code, GCC and LLVM are willing to spend seconds or even tens of seconds kneading a function over and over to win the last few percent of run-time performance. Go takes a different road: it does only the batch of optimizations with the best cost-to-benefit ratio, and hands the time it saves back to compilation speed (1.1). This is not a shortfall in ability but a clear-eyed ordering of values, and this section will return to that red line at the end. We first look at the optimizations Go is willing to do, then at Profile-Guided Optimization (PGO), introduced in Go 1.21, which pushes optimization from “static guessing” toward “data-driven.”

15.4 The Pointer Checker

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

15.4 The Pointer Checker

Go is a memory-safe language. In ordinary code, the type system guarantees that every pointer refers to a legal object of its declared type, garbage collection (13) guarantees that an object is not reclaimed while it is still referenced, and the runtime keeps out-of-bounds accesses behind bounds checks. These guarantees are not free. They rest on the premise that the compiler always knows the type and layout of every value. Yet there is always a small set of scenarios that need to step outside this system: interoperating with C (15.6) means interpreting a span of bytes according to C’s memory layout, laying out a system structure for the operating system means placing bytes one by one, and reinterpreting a []byte as a string with zero copies (5.1) means letting two types share the same underlying memory. Go leaves an escape hatch for these scenarios: the unsafe package.

15.5 Escape Analysis

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

15.5 Escape Analysis

Go programmers never manually decide whether a variable lives on the stack or the heap; the compiler’s escape analysis does it automatically. It is the unsung hero of Go’s performance: keeping as many objects on the stack as possible greatly lightens the load on the garbage collector (13 Garbage Collection). This section explains how it decides, how it is implemented, and why it matters.

15.5.1 Escape: Deciding Stack or Heap

The core question: should a variable be allocated on the stack (vanishing automatically when the function returns, at zero GC cost) or on the heap (with an indefinite lifetime, managed by the GC)? The criterion is lifetime: if a reference to a variable may still be used after the function returns, it cannot live on the stack (the stack frame is destroyed on return) and must escape to the heap. Escape analysis answers this question statically, deciding whether a variable’s address can leave the scope of the function it lives in.

15.6 cgo

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

15.6 cgo

“cgo is not Go.” This is the verdict Rob Pike handed down on cgo in a blog post. It names a thing that is easy to overlook: when you write import "C" in a Go source file and then write a single line of C.foo(), you have already stepped out of the world that the Go language drew for you and into another world, one made of C’s ABI, C’s stack, and C’s memory model. cgo is the bridge between these two worlds. The bridge is useful, but crossing it costs a toll, and the toll is not cheap.

15.7 Past, Present, and Future

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

15.7 Past, Present, and Future

The compiler is the part of the Go toolchain that changes most often, yet remains the most transparent to users. Take the same source code, change nothing, recompile it with a new version, and it often comes out faster, smaller, and better, without you ever knowing what happened in between. This section pulls the camera back to look at the road the compiler itself has traveled, then at what it is doing now and where it is heading next. Running through all of it is one unchanging order of priorities: compilation speed comes first, quality of generated code second, and both are traded off under the constraint of being engineerable (1.1).

16.1 Runtime Deadlock Detection

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

16.1 Runtime Deadlock Detection

fatal error: all goroutines are asleep - deadlock!, almost every Go programmer has seen this error. It comes from the runtime’s built-in deadlock detector. This section first makes clear how it decides and when it fires, then turns to something more important: what it can guarantee in theory, and what it is structurally unable to detect. The latter is the root of many production “hang” mysteries; understanding it is worth more than memorizing that error message.

16.2 Race Detection

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

16.2 Race Detection

A data race is the most insidious and hardest-to-reproduce class of bug in concurrent programs. Its definition is short: if two goroutines access the same memory address concurrently, at least one of them is a write, and no synchronization orders the two, then the program’s behavior is undefined (11.9). “Undefined” is not as gentle as “you read a stale value”; it means the compiler and the processor are both allowed to perform surprising reorderings, and the result may be right one time and wrong the next, may appear only under stress load, only on a certain CPU, only in a certain version, just once in a while. There is no hope of catching this kind of bug by human code review. Go’s race detector (-race) is exactly the tool that turns this from “reproduce it by luck” into “run it once and it tells you”. This section explains its principle, the algorithmic cost behind it, and the two capability boundaries you must keep in mind.

16.3 Execution Tracing

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

16.3 Execution Tracing

pprof (16.5) answers the question “which functions is the time being spent in”. It aggregates CPU samples taken over a window into a call tree and tells you that json.Marshal accounts for 30% of the CPU. But it cannot answer another class of question: a request took 50ms, and for 45ms of it the goroutine was not running at all, it was waiting. Waiting for what? A lock? The network? Interrupted by GC? Or it wanted to run but had no P available (9.2)? A CPU profile knows nothing about “waiting”, because it only samples the stack that is currently executing, and a blocked goroutine is on no CPU at all, so it is naturally never sampled.

16.4 Testing Code

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

16.4 Testing Code

Testing in Go is not a bolt-on, it is a first-class citizen of the language toolchain. go test is built in, the testing package is standard, and convention replaces configuration. This set of design choices has deeply shaped Go’s engineering culture: in other languages, “whether to write tests at all, and which framework to use” is a decision that requires weighing trade-offs; in Go it is the default action. This section explains how this machinery runs, why it was designed this way, and how it grew from unit testing all the way to Go 1.18 fuzzing.

16.5 Benchmarking and Performance Profiling

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

16.5 Benchmarking and Performance Profiling

The first principle of optimization is to measure before you act. Guessing at bottlenecks by intuition usually guesses wrong; the real hot spots are often not where you think they are. Go builds every tool this discipline requires straight into the toolchain: benchmarks answer “how fast,” profiling answers “where is it slow, where does the memory go,” and benchstat uses statistics to answer “did this change actually make things faster, or is it just noise.” This section explains all three tools thoroughly and strings them into a measurement-driven loop of “profile to find the hot spot, change, benchmark to verify.” One level up, this loop joins with PGO (15.3) and execution tracing (16.3) to form Go’s complete performance-engineering methodology.

16.6 Runtime Metrics

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

16.6 Runtime Metrics

Profiling (16.5) and tracing (16.3) belong to the family of “pull it in to diagnose when something goes wrong” tools: they cost a fair amount, produce a lot of output, and suit the case where you already suspect a problem somewhere and want to capture a window of time or a single request to look at closely. But in production the more common question is not “profile this for me right now”; it is “has this service been healthy over the past week, when did it start degrading, and should we page someone at midnight?” Answering questions like these does not rely on a one-off deep dive. It relies on continuous, low-cost, long-retainable numbers: how big the heap is, how often GC runs, whether the goroutine count is climbing, whether the tail of scheduling latency is rising. These numbers are runtime metrics.

16.7 The Language Server Protocol

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

16.7 The Language Server Protocol

Auto-completion, jump-to-definition, live error reporting, refactoring: in modern editors these features, on the Go side, are provided by gopls (the Go language server, pronounced “go please”). Behind it stands the Language Server Protocol (LSP). This section makes three things clear: the combinatorial explosion that LSP untangles, how gopls builds on the reusable libraries of the compiler frontend, and why it deserves to be called the culmination of the Go toolchain’s design philosophy.

17.1 The Hard Parts of Dependency Management

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

17.1 The Hard Parts of Dependency Management

Modern software is almost never written from scratch. For an ordinary server program, one level down the import list you find a logging library, an HTTP router, a serializer; one level further down are the cryptography, compression, and network primitives that each of those depends on. The code that is actually yours may be less than one percent of the whole dependency graph. This brings the dividend of reuse, and it also brings a question that is not yours by rights yet must be answered by you: for every package in this graph, which version should you use? This section is in no hurry to give Go’s answer; first we want to make the difficulty of the problem itself clear. There are two main threads to it: one is how to choose a version (diamond dependencies and constraint solving), the other is how to keep it from drifting once chosen (reproducible builds). Only once these two are understood can you see why the “minimum version selection” scheme of 17.3 deserves its own design, and what price Go paid to get there.

17.2 Semantic Version Management

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

17.2 Semantic Version Management

To manage versions, we first have to make version numbers mean something. 17.1 reduced the difficulty of dependency management to two points: version conflicts in diamond dependencies, and reproducible builds across machines and across time. Whether these two can be solved depends on a more basic premise, what a version number actually promises. If the relationship between v1.5 and v1.4 were entirely unpredictable, then no selection algorithm could get started, and we would be forced back to a solver that “tries every pair of versions”. The approach Go modules take is to first turn the version number into a contract a machine can trust, and then, on top of that contract, propose one distinctive and uncompromising rule, semantic import versioning. This section makes both of these clear. They are the premise on which the version selection algorithm of 17.3 can stand, and stand simply enough to be “a single graph traversal”.

17.3 Minimal Version Selection

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

17.3 Minimal Version Selection

Having settled on semantic versioning (17.2), one last question remains: when different modules in the dependency graph require different versions of the same dependency, which version do we pick? Go’s answer is a counterintuitive yet remarkably concise algorithm, Minimal Version Selection (MVS). It is the most distinctive and the most thought-provoking part of Go’s module design: other package managers turned this into a problem that needs a constraint solver, while Go compressed it into a single pass over a graph. This section first lays out the rules, then looks at why it can be this simple, and finally places it back within the broader lineage of the field to see exactly what it trades away and what it gains.

17.4 The vgo versus dep Dispute

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

17.4 The vgo versus dep Dispute

Today’s Go Modules did not exist from the start. They were born out of a rather dramatic, and rather controversial, community episode: the vgo versus dep dispute. This history is not mere gossip. It reflects the real tension among open-source project governance, technical decision-making, and community sentiment. It is the final piece for understanding why Go Modules are the way they are today, and it is also a concentrated performance, at the toolchain level, of the design philosophy this book has been discussing all along.

Closing Words: Where Is Go Headed?

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

Closing Words: Where Is Go Headed?

Having read this far, the reader has walked with the book through Go’s five major parts: its panorama and history, its language features, concurrency, memory, and the compiler and toolchain. As a conclusion, let us step back from the specific implementation details and talk about the legacy Go leaves behind, the challenges it currently faces, and where it might be headed.

What Go Leaves Behind

Looking back over the whole book, Go’s deepest legacy is perhaps not any single concrete technique, but a design stance it demonstrates again and again: place complexity where it disturbs the user least, and let simplicity be the result rather than the starting point. This thread shows itself everywhere in the book. The scheduler (9) hides the complexity of thread management inside the runtime and gives the user only a single go keyword; garbage collection (13) keeps all the subtlety of sub-millisecond pauses internal, so the user needs almost no tuning; generics (8) waited thirteen years just to find an implementation that sacrifices neither compilation speed nor simplicity; the module system (17) replaced the industry’s usual constraint solver with minimal version selection, the simplest possible algorithm. Each of these answers the same question: by what right does a given piece of complexity deserve to be introduced?

Appendix A: Glossary

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

Glossary

This appendix collects the main terms that appear in the book, grouped by topic and ordered alphabetically by their English names. For each term it gives the chapter where the term is mainly developed, so the reader can look it back up easily.

Concurrency and Scheduling

Term	Chapter	English	Abbreviation
Back Edge	9.7	Back Edge
Cooperative Preemption	9.7	Cooperative Preemption
Communicating Sequential Processes	1.3	Communicating Sequential Processes	CSP
Goroutine	9.3	Goroutine	G/g
Machine (Thread)	9.3	Machine	M/m
Network Poller	9.9	Network Poller	netpoll
Non-spinning	9.4	Non-spinning
Preemptive	9.7	Preemptive
Processor	9.3	Processor	P/p
Safepoint	9.7	Safepoint
Scheduler	9	Scheduler	sched
Spinning	9.4	Spinning
System Monitor	9.8	System Monitor	sysmon
Work Stealing	9.2	Work Stealing

Synchronization and the Memory Model

Term	Chapter	English	Abbreviation
Atomic Operation	11.3	Atomic Operation
Compare-And-Swap	11.3	Compare-And-Swap	CAS
Condition Variable	11.4	Condition Variable
Data Race	11.9	Data Race
Happens-Before	11.9	Happens-Before
Lock-free	11.3	Lock-free	LF
Memory Barrier	11.9	Memory Barrier
Sequential Consistency	11.9	Sequential Consistency	SC
False Sharing	12.2	False Sharing
True Sharing	12.2	True Sharing
Wait-free	11.3	Wait-free

Memory Allocation

Term	Chapter	English	Abbreviation
Arena	12.3	Arena	heapArena
Arena Hint	12.3	Arena Hint	arenaHint
Fast Path	12.1	Fast Path
Free List	12.2	Free List
Heap	12	Heap
Large Object	12.4	Large Object
Page	12.7	Page
Page Allocator	12.7	Page Allocator
Size Class	12.1	Size Class
Small Object	12.5	Small Object
Slow Path	12.1	Slow Path
Tiny Allocator	12.6	Tiny Allocator
Tiny Object	12.6	Tiny Object

Garbage Collection

Term	Chapter	English	Abbreviation
Bitmap	13.5	Bitmap
Collector	13.1	Collector
Conservative	13.7	Conservative
Finalizer	13.10	Finalizer
Garbage Collection	13	Garbage Collection	GC
Generational Hypothesis	13.8	Generational Hypothesis
Hybrid Write Barrier	13.2	Hybrid Write Barrier
Liveness	13.1	Liveness
Mark Assist	13.4	Mark Assist
Mark-Sweep	13.1	Mark-Sweep
Mutator	13.1	Mutator
Pacer	13.3	Pacer
Reachability	13.1	Reachability
Remembered Set	13.8	Remembered Set
Stop the World	13.3	Stop the World	STW
Tricolour Abstraction	13.1	Tricolour Abstraction
Write Barrier	13.2	Write Barrier	WB/wb

Execution Stack

Term	Chapter	English
Contiguous Stack	14.1	Contiguous Stack
Prologue	2.2	Prologue
Epilogue	14.3	Epilogue
Stack	14	Stack
Stack Copy	14.4	Stack Copy
Stack Growth	14.3	Stack Growth

Language Features and the Compiler

Term	Chapter	English	Abbreviation
Calling Convention	2.2	Calling Convention / ABI
Defer Bit	6.2	Defer Bit
Devirtualization	15.3	Devirtualization
Escape Analysis	15.5	Escape Analysis
GC Shape	8.1	GC Shape
Inlining	15.3	Inlining
Interface Table	4.2	Interface Table	itab
Open-coded Defer	6.2	Open-coded Defer
Profile-Guided Optimization	15.3	Profile-Guided Optimization	PGO
Static Single Assignment	15.2	Static Single Assignment	SSA
Type Set	8.3	Type Set
Type Descriptor	4.1	Type Descriptor	_type

Modules and the Toolchain

Term	Chapter	English	Abbreviation
Language Server Protocol	16.7	Language Server Protocol	LSP
Minimal Version Selection	17.3	Minimal Version Selection	MVS
Race Detector	16.2	Race Detector
Semantic Import Versioning	17.2	Semantic Import Versioning
Semantic Versioning	17.2	Semantic Versioning	semver

Support the Author

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

Support the Author

Thank you for reading this far. This book has been free and open from beginning to end, and from the very first line until now, the entire cost of writing, proofreading, and updating it has been borne by the author alone. If these words once helped you make sense of an obscure piece of source code late at night, or saved you some time fumbling through a problem at work, the author would be glad to hear it.

Go: Under the Hood

Preface

Preface

How to Read This Book

How to Read This Book

1.1 The Evolution of Programming Languages

1.1 The Evolution of Programming Languages

1.2 An Overview of the Go Language

1.2 An Overview of the Go Language

1.3 Communicating Sequential Processes

1.3 Communicating Sequential Processes

2.1 The Plan 9 Assembly Language

2.1 The Plan 9 Assembly Language

2.2 Stack Frames and Symbols in Assembly

2.2 Stack Frames and Symbols in Assembly

2.3 Calling Convention and the Register ABI

2.3 Calling Convention and the Register ABI

2.4 Argument Passing and Stack Frame Layout

2.4 Argument Passing and Stack Frame Layout

3.1 Starting from the `go` Command

3.1 Starting from the go Command

3.2 The Go Compilation Pipeline

3.2 The Go Compilation Pipeline

3.3 Bootstrapping the Language

3.3 Bootstrapping the Language

3.4 Module Linking

3.4 Module Linking

3.5 Bootstrapping a Go Program

3.5 Bootstrapping a Go Program

3.6 The Life and Death of the Main Goroutine

3.6 The Life and Death of the Main Goroutine

4.1 The Runtime Type System

4.1 The Runtime Type System

4.2 Interfaces

4.2 Interfaces

4.3 Type Aliases

4.3 Type Aliases

5.1 Arrays and Slices

5.1 Arrays and Slices

5.2 Strings and Zero-Copy Conversion

5.2 Strings and Zero-Copy Conversion

5.3 Hash Tables: Principles and Security

5.3 Hash Tables: Principles and Security

5.4 Swiss Table and the Go 1.24 Implementation

5.4 Swiss Table and the Go 1.24 Implementation

6.1 Function Calls

6.1 Function Calls

6.2 Deferred Statements

6.2 Deferred Statements

6.3 The panic and recover Builtins

6.3 The panic and recover Builtins

7.1 The Evolution of the Problem

7.1 The Evolution of the Problem

7.2 Inspecting Error Values

7.2 Inspecting Error Values

7.3 Error Format and Context

7.3 Error Format and Context

7.4 Error Semantics

7.4 Error Semantics

7.5 The Future of Error Handling

7.5 The Future of Error Handling

8.1 The Evolution of Generics Design

8.1 The Evolution of Generics Design

8.2 Contract-Based Generics

8.2 Contract-Based Generics

8.3 Type-Checking Techniques

8.3 Type-Checking Techniques

8.4 The Future of Generics

8.4 The Future of Generics

9.1 The Scheduling Problem and the GMP Model

9.1 The Scheduling Problem and the GMP Model

9.2 Work-Stealing Scheduling

9.2 Work-Stealing Scheduling

9.3 The MPG Model and the Units of Concurrent Scheduling

9.3 The MPG Model and the Units of Concurrent Scheduling

9.4 The Scheduling Loop

9.4 The Scheduling Loop

9.5 Thread Management

9.5 Thread Management

9.6 Signal Handling

3.1 Starting from the `go` Command