Глава 3 Жизнь программы on Go: Under the Hood

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.

Глава 3 Жизнь программы on Go: Under the Hood

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 Жизнь и смерть главной горутины

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