Go: Under the Hood

Введение

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

Введение

Язык Go существует уже более десяти лет с момента его появления в 2009 году. Оглядываясь на историю большинства языков программирования, удивительно то, что за эти годы эволюции Go сам язык не претерпел сильных изменений, и пользователи Go смогли продолжать писать приложения, сохраняющие обратную совместимость. С точки зрения дизайна языка, Go с самого начала создавался на принципах низкой стоимости, высокой конкурентности и простоты, и сложно не заинтересоваться механизмами реализации и конкретными принципами работы, стоящими за таким простым дизайном. Эта книга обсуждает технические принципы исходного кода Go и путь их эволюции.

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 Начинаем с команды `go`

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

3.1 Начинаем с команды `go`

Жизненный цикл программы на Go начинается с запуска команды go. Команды go build, go test и go run, которые читатель набирает каждый день, на первый взгляд лишь «превращают исходный код в бинарный файл», но за ними скрывается факт, который часто понимают неверно: go сама по себе не является компилятором. Это оркестратор сборки, который разбивает единый процесс на множество отдельных шагов, определяет их порядок и степень параллелизма, а затем последовательно вызывает настоящие инструменты: компилятор compile (3.2), ассемблер asm и линкер link (3.4). В этом разделе мы сначала проясним саму схему оркестрации — она задаёт структуру для всех последующих разделов: поняв, как go декомпозирует сборку в граф и как использует кэш на основе содержимого для устранения повторной работы, читатель получит опору для погружения в детали компиляции и линковки.

3.2 Конвейер компиляции Go

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

3.2 Конвейер компиляции Go

В разделе 3.1 было показано, что реальную работу go build выполняют две программы — compile и link. Этот раздел фокусируется на compile и прослеживает полный путь от одного исходного файла .go до одного объектного файла .o: что получает каждая стадия, что она порождает и почему работа разделена именно так. Этот раздел представляет собой панораму конвейера компиляции. Внутреннее устройство каждой стадии (как устроена грамматика, какой алгоритм используется для проверки типов, правила оптимизации SSA) раскрывается в главе 15. Здесь мы лишь выстраиваем их в единую линию и указываем на две сквозные темы.

3.3 Бутстрап языка

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

3.3 Бутстрап языка

Один вопрос звучит как парадокс: компилятор, ассемблер, компоновщик и рантайм Go сегодня написаны на Go, так откуда же взялась первая программа, способная скомпилировать Go? Без компилятора Go — как скомпилировать компилятор Go? Это и есть бутстрап (bootstrapping). Он представляет собой одновременно и классическую дилемму курицы и яйца, и конкретный инженерный эпизод из истории инструментария Go, который можно пересказать с точностью до деталей. В этом разделе даётся ответ на три вопроса: как это яйцо было высижено впервые; как после бутстрапа работает цепочка сборки новой версии Go и почему требования к версии бутстрапа растут год от года; и наконец, почему язык, который «реализует себя средствами самого себя», заслуживает серьёзного отношения.

3.4 Компоновка модулей

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

3.4 Компоновка модулей

Компилятор (3.2) преобразует каждый пакет в объектный файл, но объектный файл сам по себе не может быть выполнен. Объектные файлы по-прежнему ссылаются на функции и переменные друг друга, адреса ещё не зафиксированы, а поддержка рантайма отсутствует. Сборка этих фрагментов в цельную программу, пригодную для загрузки и исполнения, — задача компоновщика (cmd/link, обычно вызываемого через go build как go tool link). В этом разделе рассматривается, что делает компоновщик и какие решения Go принимает в области компоновки, — именно они объясняют, почему Go-программа так часто представляет собой единственный самодостаточный файл, который «просто работает после копирования на целевую машину».

3.5 Начальная загрузка Go-программы

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

3.5 Начальная загрузка Go-программы

Функция main, которую пишет читатель, не является первой инструкцией программы. Когда операционная система передаёт управление исполняемому файлу Go, первым начинает работу рантайм: он должен разметить стек выполнения на главном потоке, привязать локальное хранилище потока (TLS), определить количество ядер CPU и размер физической страницы памяти, последовательно пробудить аллокатор памяти, сборщик мусора и шедулер, и лишь затем создать горутину, несущую main, и передать её в цикл планирования для запуска. Иначе говоря, бинарный файл Go содержит внутри себя миниатюрную операционную систему (1.2), которая запускается раньше пользовательского кода. В этом разделе мы пройдём всю цепочку начальной загрузки от начала до конца — от точки входа, определённой операционной системой, до момента планирования первой горутины, — чтобы ясно увидеть, что происходит «до main».

3.6 Жизнь и смерть главной горутины

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

3.6 Жизнь и смерть главной горутины

В 3.5, после того как schedinit собрал фундамент рантайма, прямого вызова runtime.main не происходит. Вместо этого адрес точки входа этой функции помещается на стек, передаётся в newproc для создания первой горутины, а затем mstart запускает цикл планирования и выбирает эту горутину для выполнения. Детали планирования оставлены для 9 Шедулер. В данном разделе внимание сосредоточено на одном конкретном моменте: первая горутина уже запущена и готова выполнить 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 Задача планирования и модель GMP

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

9.1 Задача планирования и модель GMP

Достаточно написать go f() — и горутина начинает выполняться. За этой единственной строкой стоит самый сложный механизм рантайма Go: планировщик (шедулер). Он должен ответить на вопрос, который совсем не прост: каким образом десятки тысяч горутин могут поочерёдно использовать небольшое число ядер процессора, работая быстро и оставаясь при этом практически незаметными для пользователя. В этом разделе сначала формулируется задача, которую должен решить планировщик, описывается его общая структура и место среди других конкурентных рантаймов. Последующие разделы подробно рассматривают каждый компонент.

9.2 Планирование с кражей работы

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

9.2 Планирование с кражей работы

9.1 оставил нам вопрос: у каждого P есть собственная локальная очередь, а значит, работа неизбежно распределяется неравномерно. Одни P перегружены, другие простаивают. Как распределить нагрузку, не создавая центрального узкого места, — это основная трудность конкурентного планирования. Ответ Go — схема с тридцатилетней теоретической базой, воспроизводимая во всей отрасли: кража работы (work stealing).

Этот раздел несколько глубже остальных. Сначала мы проясним, что именно делает Go, затем проследим стоящую за этим теорию планирования (почему кража работы «доказуемо хороша»), далее рассмотрим различные воплощения этой идеи в системах вроде Cilk, Java и Rust и, наконец, остановимся на вопросах, которые остаются открытыми.

9.3 Модель MPG и единицы конкурентного планирования

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

9.3 Модель MPG и единицы конкурентного планирования

Первый вопрос, на который должен ответить шедулер, — не «как планировать», а «что планировать». Go называет объект планирования горутиной и реализует её на тройке M, P и G. Прежде чем перейти к алгоритму планирования (начиная с 9.4), этот раздел разбирает три единицы планирования: что такое горутина в контексте истории информатики, как кодируется её контекст выполнения, почему само планирование должно происходить на специальном g0, через какие состояния проходит горутина за свою жизнь и как поток M, несущий её, приостанавливается и возобновляется. Когда эти понятия прояснятся, все последующие алгоритмы планирования сведутся к «перемещению G между этими единицами».

9.4 Цикл планирования

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

9.4 Цикл планирования

Предыдущие разделы подготовили материал: мы знаем, что такое G, M и P (9.3), и знаем, как M находит работу (9.2). Этот раздел запускает всё в движение — мы наблюдаем, как цикл планирования непрерывно выбирает горутины и выполняет их в рамках одного потока, и как он удерживает баланс между «позволить отдельной горутине чуть дольше занимать процессор» (пропускная способность и локальность) и «не позволить ни одной горутине оголодать» (справедливость).

9.5 Управление потоками

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

9.5 Управление потоками

9.1 заложил трёхуровневую структуру GMP: G — единица выполнения на уровне пользователя, P — разрешение на планирование и носитель локальных ресурсов, а M — «нога», одолженная у операционной системы. Предыдущие разделы сосредоточились преимущественно на G и P; этот раздел переключает внимание на M и отвечает на ряд вопросов, откладывавшихся до сих пор: что такое M на самом деле, откуда он берётся, почему GOMAXPROCS ограничивает количество P, тогда как число потоков нередко оказывается больше, почему единственный блокирующий системный вызов не тормозит остальные G, и какую цену платит рантайм, когда пользователь хочет закрепить горутину за конкретным потоком (LockOSThread).

9.6 Обработка сигналов

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

9.6 Обработка сигналов

Сигналы операционной системы асинхронны и низкоуровневы: сигнал может прервать любой поток в произвольный момент, а набор действий, допустимых в обработчике сигнала, крайне ограничен. Типичный же запрос разработчика на Go — подключить канал к SIGINT через signal.Notify и выполнить корректное завершение по его приходу. Задача рантайма — выстроить мост между этими двумя реальностями: преобразовать непредсказуемый асинхронный сигнал в событие, которое горутина сможет безопасно обработать. Каждое проектное решение на этом мосту диктуется одним жёстким ограничением: что допустимо делать внутри контекста обработчика сигнала. Понимая это ограничение, всю остальную механику данного раздела можно воспринимать как её следствия.

9.7 Кооперация и вытеснение

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

9.7 Кооперация и вытеснение

В 9.5 Цикл планирования остался открытый вопрос: если некоторая G выполняется слишком долго, как остальные G всё равно смогут получить время процессора? Ответ неизбежно апеллирует к паре понятий из теории планирования — кооперативному и вытесняющему. Кооперативное планирование опирается на добровольную уступку управления планируемой стороной; вытесняющее — на прерывание планируемой стороны планировщиком извне.

Рантайм Go не располагает возможностью аппаратного прерывания, подобной ядру операционной системы. Планировщик с перехватом работы (9.2) по своей сути является кооперативным планированием в порядке поступления. Вопрос в том, как он всё же способен принудительно прерывать G, отказывающуюся уступать управление, не отступая при этом от данного принципа — именно это и предстоит прояснить в настоящем разделе. Отправной точкой служит теоретический вопрос: почему рантайм не может остановить горутину в произвольной инструкции?

9.8 Системный монитор

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

9.8 Системный монитор

Штатный путь планировщика описан в 9.4 Цикл планирования: один M привязывается к одному P, извлекает горутину из очереди, выполняет её, затем берёт следующую. Этот путь опирается на одно условие — что M вообще получает возможность работать. Но стоит всем P застрять в длительных системных вызовах, или какой-либо горутине уйти в бесконечный цикл и намертво удерживать P, — обычное планирование встаёт. Никто не забирает P обратно, никто не опрашивает сеть. Иными словами, кооперативная логика, выполняемая на P, не способна справиться с ситуацией, когда «сам P не может двигаться».

9.9 Опросчик сети

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

9.9 Опросчик сети

Исходные факты верифицированы по src/runtime/netpoll.go и его платформенным реализациям (netpoll_epoll.go, netpoll_kqueue.go и другим), а также по src/internal/poll/fd_unix.go.

Сетевой код Go выглядит блокирующим: conn.Read просто «зависает» в ожидании данных. Но если бы он действительно блокировал поток операционной системы, на котором выполняется, то десять тысяч горутин, ожидающих данных из сети, удерживали бы десять тысяч потоков, и модель M:N, тщательно выстроенная в 9.1, мгновенно рухнула бы. Возможность сохранить блокирующий стиль и при этом обеспечить масштабируемость — заслуга опросчика сети (netpoller). За ним стоит долгая история «как обслуживать огромное число соединений с помощью горстки потоков». Этот раздел сначала излагает эту историю и определяющие оси проектирования, а затем рассматривает, как Go скрывает зрелый механизм событий внутри рантайма: программист пишет синхронный код, а под капотом работает событийно-ориентированный ввод-вывод.

9.10 Таймеры

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

9.10 Таймеры

time.Sleep, time.After, time.Timer, time.Ticker и даже SetDeadline для сетевого чтения и записи — всё это опирается на одну и ту же инфраструктуру таймеров. Она должна отвечать на вопрос, который выглядит простым, но на деле весьма тонок — вопрос о структурах данных: когда одновременно существуют тысячи таймеров, как эффективно определить «кого нужно разбудить следующим, и когда», не выжигая при этом отдельный поток? Этот раздел начинается с постановки абстрактной задачи, разбирает компромиссы различных решений и приходит к выбору Go и его эволюции.

9.11 NUMA-осведомлённость и будущее планировщика

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

9.11 NUMA-осведомлённость и будущее планировщика

Планировщик, описанный в предыдущих разделах, опирается на предположение, которое нигде явно не сформулировано: каждый M обращается к памяти с одинаковой скоростью, а стоимость перемещения G между любыми двумя P одинакова. На ноутбуке или однопроцессорном сервере это предположение почти верно. Но стоит запустить программу на крупном многопроцессорном сервере — оно начинает трещать, и чем больше ядер, тем шире трещина. Этот раздел посвящён именно ей: откуда она берётся, почему планировщик Go так долго её игнорировал, какой NUMA-осведомлённый дизайн был тщательно проработан, но так и не выпущен, и как пользователи обходят проблему сегодня.

10.1 Каналы и инженерия CSP

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

10.1 Каналы и инженерия CSP

К этому разделу прилагается записанный доклад: онлайн на YouTube, презентация в Google Slides.

CSP даёт Go основание утверждать: процессы не разделяют состояние, а координируются исключительно через передачу сообщений (1.3). Настоящий раздел посвящён другому вопросу: чтобы инженерный язык воплотил это утверждение на практике, какую форму должна принять «коммуникация», при которой обычный программист мог бы использовать её корректно. Ответ Go — канал, элемент языка первого класса, являющийся одновременно средством синхронизации и средством передачи данных. Мы начнём с изложения его модели на поверхности языка: тип, синтаксис отправки и приёма, две семантики — буферизованная и небуферизованная, ограничение направления и поведение nil — выстраивая интуицию, которая понадобится последующим разделам при погружении в реализацию рантайма (10.2–10.7).

10.2 hchan: внутреннее устройство канала

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

10.2 hchan: внутреннее устройство канала

10.1 рассмотрел каналы в языке с позиции CSP: канал — это явный передаточный механизм для сообщений, объединяющий «коммуникацию» и «синхронизацию» в единое целое. Данный раздел разбирает его изнутри. В рантайме канал представлен структурой hchan, весь секрет которой сводится к единственной блокировке, кольцевому буферу и двум очередям ожидания. Структура невелика, однако каждое поле существует по конкретной проектной причине. Стоит уяснить эти немногие элементы — и вся последующая логика отправки, получения и select (10.3–10.6 Модель памяти и эволюция в сторону lock-free) окажется лишь «перемещением данных, парковкой и пробуждением горутин поверх этой единственной картины».

10.3 Отправка, получение и прямая передача

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

10.3 Отправка, получение и прямая передача

10.2 очертил скелет hchan: мьютекс, кольцевой буфер buf, а также очередь отправителей sendq и очередь получателей recvq. Настоящий раздел оживляет этот скелет и отвечает на вопрос, что именно происходит внутри рантайма при одиночном ch <- v и одиночном v := <-ch. Разобравшись в этом пути отправки/получения, оба наиболее часто задаваемых вопроса о каналах — почему небуферизованный канал является единственной точкой рандеву и почему для него получение происходит прежде, чем завершается соответствующая отправка (11.9), — сводятся к одному механизму: прямой отправке / прямому получению.

10.4 Семантика закрытия канала

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

10.4 Семантика закрытия канала

В предыдущих разделах операции отправки и получения были «парными» рандеву: одна отправка соответствует одному получению, а избыточная сторона блокируется в ожидании. Закрытие — единственная операция над каналом с семантикой «один ко многим». close(ch) вызывается одной горутиной, однако в тот же момент пробуждает всех получателей, заблокированных на канале, и заставляет немедленно запаниковать всех заблокированных отправителей. Эта возможность «однократного широковещания, пробуждающего всех» превращает закрытие из, казалось бы, малозначимой операции очистки в наиболее распространённый в Go механизм отмены и завершения работы. Паттерн done-канала и отмена через context (11.8) восходят именно к этой семантике.

10.5 Реализация select

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

10.5 Реализация select

Предыдущие разделы детально рассмотрели отправку и приём данных по одному каналу (10.3). На практике, однако, горутина редко наблюдает лишь один канал: требуется реагировать на первую готовую операцию из нескольких отправок и приёмов и при этом избегать блокировки, если ни одна из них не готова. select создан именно для этого. Его семантика выглядит просто, однако реализация должна одновременно решить две нетривиальные задачи: как справедливо выбрать ветку, когда несколько из них готовы, и как избежать взаимоблокировки при захвате нескольких каналов в рамках одного select. Оба требования определяют всю структуру selectgo, и данный раздел построен вокруг них.

10.6 Модель памяти и эволюция без блокировок

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

10.6 Модель памяти и эволюция без блокировок

Предыдущие разделы разобрали канал до составных частей: прямая передача в 10.3 позволяет отправляющей и принимающей сторонам передавать значение напрямую, минуя кольцевой буфер, а select в 10.5 делает случайный выбор среди нескольких готовых веток. Эти механизмы объясняют, как канал «работает». Настоящий раздел отвечает на два вопроса более высокого уровня: какую гарантию видимости канал даёт конкурентной программе, и на один инженерный вопрос, который поднимается нередко, — почему канал по сей день остаётся «мьютексом плюс очередью», а не предположительно более быстрой структурой без блокировок. Первый вопрос связывает канал с моделью памяти в 11.9; второй представляет собой реальный компромисс о том, «как корректность и сопровождаемость побеждают пиковую производительность».

10.7 Инженерная практика и межъязыковое сравнение

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

10.7 Инженерная практика и межъязыковое сравнение

В предыдущих разделах мы разобрали внутреннее устройство канала, пути отправки и получения данных, а также реализацию select на самом низком уровне. Разобравшись в механизме, закономерно встаёт более трудный и практически ориентированный вопрос: когда следует использовать канал, а когда — нет. Слоган Go «не общайтесь через разделяемую память; вместо этого делитесь памятью через общение» легко прочитать как «любое разделяемое состояние должно проходить через канал», но это не то, что имел в виду его автор. Данный раздел сводит этот слоган к конкретному практическому правилу, сопоставляет его с более лёгкими инструментами из главы о примитивах синхронизации (Глава 11), а затем помещает выбор Go в контекст семейства CSP, чтобы понять его конкретные координаты в пространстве проектных решений.

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 Мьютекс

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

11.2 Мьютекс

sync.Mutex — наиболее фундаментальный примитив синхронизации: он допускает в критическую секцию лишь одну горутину одновременно. За этим простым интерфейсом скрывается постоянное балансирование между двумя конкурирующими целями: пропускная способность (передать блокировку как можно быстрее, не оставляя процессор простаивать) и справедливость (не допускать бесконечного ожидания в очереди). Достичь обеих целей в полной мере невозможно: передача блокировки строго по порядку поступления наиболее справедлива, однако сопряжена с переключением контекста при каждой передаче; предоставление только что пробудившемуся ожидающему свободно конкурировать с уже выполняющимися горутинами — наиболее быстро, однако чревато тем, что некоторые ожидающие будут проигрывать снова и снова. Данный раздел сначала излагает теорию и аппаратные основы классической задачи взаимного исключения, а затем рассматривает, как мьютекс Go держит этот баланс.

11.3 Атомарные операции

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

11.3 Атомарные операции

sync/atomic — это уровень примитивов синхронизации Go, расположенный ближе всего к аппаратуре. Все более высокоуровневые инструменты — мьютекс (11.1) и каналы (8) — внутри построены на атомарных операциях. Пакет обеспечивает «неделимые» чтения, записи и операции «чтение–модификация–запись»: атомарная операция либо выполняется целиком, либо не выполняется вовсе, и ни одна горутина никогда не видит её в незавершённом состоянии. Однако смысл атомарных операций простирается далеко за пределы «отсутствия частичной записи». Они составляют фундамент неблокирующего (lock-free) программирования, а за неблокирующим программированием стоит глубокая теория о том, «какой примитив на что способен». Именно эту теорию данный раздел стремится прояснить.

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”.

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 Green Tea: Locality-Aware Marking

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

13.11 Green Tea: Locality-Aware Marking

The previous sections framed marking as a matter of being “correct and timely”: the write barrier (13.2) guarantees nothing live is missed, and mark assist (13.4) guarantees marking keeps up with allocation. Yet neither touches another account in marking’s ledger: how fast marking actually runs. On today’s multi-core, large-heap machines, the bottleneck of marking often lies neither in the algorithm’s correctness nor in the CPU’s raw compute, but in the memory wall: the processor spends most of its time not computing but waiting for one cache miss after another to return. Green Tea goes straight at that account.

13.12 Past, Present, and Future

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

13.12 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.13 A Unified Theory of Garbage Collection

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

13.13 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.

18.1 Crossing the FFI Boundary

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

18.1 Crossing the FFI Boundary

15.6 already took the cgo bridge apart: a call from Go into C must switch to the g0 system stack, lay the arguments out again according to C’s ABI, entersyscall to give up the P, make the call, then exitsyscall to win back a P, and the whole round comes out one or two orders of magnitude more expensive than a Go call. The conclusion of that section was blunt: cgo suits a small number of coarse-grained calls, and its worst enemy is a hot loop that crosses the boundary again and again.

18.2 The Scheduler and Blocking Foreign Calls

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

18.2 The Scheduler and Blocking Foreign Calls

The prescription 18.1 gave was “asynchronous, synchronize seldom”: push commands into the stream, return immediately, wait only once at the end. But that “once at the end” must after all be waited. cudaStreamSynchronize blocks until the GPU has drained the whole stream; a synchronous cudaMemcpy, a driver call that does not take the asynchronous path, will all leave the Go-side thread genuinely stopped inside C. What this section asks is this: when a crossing really does block for a long time, how does the scheduling machinery of Chapter 9 react? Will it be dragged down by a single call stuck on the GPU?

18.3 The Divide Between Device Memory and the Garbage Collector

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

18.3 The Divide Between Device Memory and the Garbage Collector

15.6 covered cgo’s pointer rules: Go’s objects do not belong to C, the GC may move or reclaim them at any time, and so C must not hold an unpinned Go pointer after the call returns. That was deduced from a binary world of “two memories, Go’s and C’s.” The GPU complicates this map: now there are at least four kinds of memory, under different jurisdictions and obeying different rules. This section first draws that map clearly, then sees where the dividing lines between the garbage collector and each of them fall, and which line is most easily trampled in asynchronous transfers.

18.4 The Asynchronous Programming Model

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

18.4 The Asynchronous Programming Model

The previous three sections all spoke of the “costs” on the FFI boundary: cross fast (18.1), crossing occupies a thread (18.2), who owns the memory on the bridge (18.3). This section changes the angle and returns to the concurrency model itself. Go’s concurrency is goroutines and channels, the GPU’s concurrency is something else, and the CPU hides a third kind. Laying these three parallelisms out clearly and seeing how they connect is the close of this chapter, and the key to understanding “when to push the work across the boundary, and when there is no need at all.”

19.1 The Rendering Pipeline and Where Go Sits

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

19.1 The Rendering Pipeline and Where Go Sits

Chapter 18 read the GPU as a “general-purpose parallel compute device.” But the GPU’s given name is the Graphics Processing Unit, and its first and most native job is to render graphics. For the two decades before “using the GPU for general computation” became a slogan, the graphics card was already doing parallel arithmetic for every pixel on the screen. Graphics is therefore the oldest heterogeneous workload: the massively parallel hardware on a GPU was built for it in the first place. This chapter returns to that origin to ask what role Go plays in graphics, and the starting point is to see clearly the rendering pipeline that runs through everything, and where exactly Go’s code sits on it.

19.2 Graphics Bindings and Thread Affinity

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

19.2 Graphics Bindings and Thread Affinity

19.1 said that Go sits at the application stage of the pipeline and is responsible for issuing draw calls. But before the first draw call can actually go out, there is a threshold in front of every Go graphics program. It does not come from graphics itself, but from a fundamental conflict between Go’s concurrency model and a property of graphics APIs: a graphics context is bound to a thread, while a goroutine migrates across threads. This threshold is the subject of this section, and the key that 18.2.5 handed us, LockOSThread, turns here from an optional trick into a necessity.

19.3 Software Rendering and Parallelism

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

19.3 Software Rendering and Parallelism

Rendering in the previous two sections always crossed a boundary: hand the work and commands to the local GPU, pay the whole set of tolls from Chapter 18, and still attend to the thread discipline of the graphics context (19.2). This section takes another road, software rendering: compute every pixel entirely on the CPU, touching no GPU, no driver, no FFI boundary of any kind. This road was once dismissed as “the slow and useless fallback,” yet it is precisely the best stage on which to put Go’s concurrency, and Go 1.27’s simd, to work in graphics.

19.4 Rendering in the Browser

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

19.4 Rendering in the Browser

Rendering in the previous three sections either pushed the work across the FFI boundary to the local GPU (19.1, 19.2) or kept it on the CPU as software rendering (19.3). This section changes the scene to a special runtime environment: the browser. Go can be compiled to WebAssembly (WASM) and run in the browser, and once inside the browser, rendering meets a brand-new boundary. What is interesting is that the shape of this boundary, its cost, and the way to deal with it correspond almost one to one with the heterogeneous computing of the previous two chapters, only lifted up one level. Understanding this section reveals that “the FFI boundary” is a motif far broader than cgo.

20.1 The Inference Runtime and FFI

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

20.1 The Inference Runtime and FFI

The FFI boundary that recurred through Chapters 18 and 19 wears, with large models, its most current face. Training large models is almost the domain of Python and CUDA, but when a model is trained and is to be deployed to serve tens of millions of requests, the lead role changes, and Go stands firm at this layer. This chapter is about how Go takes on AI’s inference and serving, and the first section must settle the lowest-level problem: Go does not do matrix multiply itself, it has to wire in a local inference runtime, and this wiring is, once again, the boundary of Chapter 18.

20.2 Tokenization and Tensors

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

20.2 Tokenization and Tensors

20.1 settled the home of weights and tensors on the native runtime side, with Go only passing handles and moving small data on the boundary. This section steps into that “small data” itself: how text becomes the numbers a model can eat, and how the numbers turn back into text. This seemingly trivial thing hides a detail that will make a Go programmer smile in recognition, for it is almost a direct application of Chapter 5’s “a string is a stretch of immutable bytes,” and the moment it is neglected, it spits out garbled text in streaming output.

20.3 Serving, Batching, and Streaming

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

20.3 Serving, Batching, and Streaming

The previous two sections laid the underpinnings of a single inference: 20.1 wired in the runtime through cgo and settled the weights and tensors, 20.2 made clear how tokens go in and come out. But a real service must serve thousands upon thousands of such requests at once, each continuously spitting tokens. How to organize them efficiently and stably is a thoroughly concurrency and scheduling problem, and this is Go’s home ground. This section brings Chapter 10’s channels and Chapter 7’s context down to large-model serving.

21.1 The Agent Control Loop

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

21.1 The Agent Control Loop

Chapter 20 was about Go serving a model: a request goes in, a stream of tokens comes out. But systems today often go a step further: they let the model not only answer, but also call tools, chain together multiple steps, and drive itself forward until a task is done. This is the AI agent. The word sounds mysterious, but the stance of this book is unchanged: set the model’s intelligence aside and look only at the runtime side. Seen this way, an agent is nothing more than a control loop, and the control loop is one of the oldest and plainest structures in computer science. This chapter uses that lens to reduce an agent to a concurrency problem a Go programmer already knows.

21.2 Tool Calls and MCP

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

21.2 Tool Calls and MCP

21.1 reduced an agent to a control loop, and the most important action inside that loop is “execute a tool”. This section is about tools specifically: what a tool is mechanically, how the model decides to call it, how the runtime dispatches the call to real code, and how, when the number and the sources of tools explode, the Model Context Protocol (MCP) standardizes the whole thing with a single protocol. See through this layer and you find that a tool call is, in essence, a structured remote procedure call, and RPC is exactly Go’s old trade.

21.3 Streaming, Backpressure, and Cancellation

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

21.3 Streaming, Backpressure, and Cancellation

21.1 stood up the agent’s control loop, and 21.2 made the tool calls inside it clear. This last section brings the context of Chapter 7 and the concurrency primitives of Chapters 10 and 11 onto the stage for the book’s curtain call, because the real difficulty of a production-grade agent lies not in the skeleton of the loop but in three things that run through the entire chain: streaming, backpressure, and cancellation. They are intertwined, and what unifies them is a shape a Go programmer knows all too well, a tree of goroutines bound by a context.

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 six major parts: its panorama and history, its language features, concurrency, memory, the compiler and toolchain, and heterogeneous compute and AI. 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.

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

Введение

Введение

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 Начинаем с команды `go`

3.1 Начинаем с команды go

3.2 Конвейер компиляции Go

3.2 Конвейер компиляции Go

3.3 Бутстрап языка

3.3 Бутстрап языка

3.4 Компоновка модулей

3.4 Компоновка модулей

3.5 Начальная загрузка Go-программы

3.5 Начальная загрузка Go-программы

3.6 Жизнь и смерть главной горутины

3.6 Жизнь и смерть главной горутины

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 Задача планирования и модель GMP

9.1 Задача планирования и модель GMP

9.2 Планирование с кражей работы

9.2 Планирование с кражей работы

9.3 Модель MPG и единицы конкурентного планирования

9.3 Модель MPG и единицы конкурентного планирования

9.4 Цикл планирования

9.4 Цикл планирования

9.5 Управление потоками

9.5 Управление потоками

9.6 Обработка сигналов

3.1 Начинаем с команды `go`