Escape analysis в Go

Правило одно, и его видно глазами

Взял функцию func New() *T { t := T{a: 1}; return &t } и собрал с -gcflags=-m. Компилятор напечатал: moved to heap: t. Он увидел, что адрес уходит наружу и переживёт вызов, поэтому переложил значение в кучу.

Кадр стека - это кусок памяти под локальные переменные одного вызова: кончился вызов, кадр отброшен. Правило анализа ровно одно. Значение, которое свой кадр не переживёт, остаётся на стеке, потому что там выделение это сдвиг указателя, а освобождение бесплатное. Всё, что кадр переживает, уезжает в кучу под присмотр сборщика.

// Поэтому вернуть адрес локальной переменной в Go безопасно, в отличие от C. Повисшего указателя не будет: компилятор сам заметит и разместит значение так, чтобы оно жило. Конструктор func New() *T { return &T{} } - обычная идиома, а не грех.

кадр стека

память под локальные переменные одного вызова

moved to heap

строка компилятора: переменную переложили в кучу

Куда именно утекает, и почему инлайн всё переворачивает

Тот же прогон, четыре характерные строки. make([]int, 8) does not escape - размер известен при компиляции, влезло на стек. make([]int, n) escapes to heap - размер узнаём в рантайме, места на стеке заранее не отвести. moved to heap: x вместе с func literal escapes to heap - переменную замкнули в функции, живущей дольше кадра. И n escapes to heap на строке с fmt.Println.

Последнее и есть цена боксинга. Параметр fmt.Println имеет тип any, а укладка значения в интерфейс требует адреса, поэтому значение отправляется в кучу. В моём выводе так уехали даже строковые константы. Логирование в горячем цикле дороже, чем выглядит.

// Забавное место: тот же &T{} в одной строке escapes to heap, а в другой does not escape. Разница в инлайне - когда компилятор встроил New прямо в вызывающий код, кадр стал общим, и переживать стало нечего. Вывод -gcflags=-m читают вместе со строками can inline, иначе он кажется противоречивым.

боксинг

укладка значения в интерфейс, уводит его в кучу

escapes to heap

строка компилятора: значение размещено в куче

Когда за это вообще браться

Порядок работы такой. Сперва бенчмарк с -benchmem: он печатает allocs/op, число аллокаций на операцию. Потом профиль кучи: он говорит, сколько и откуда. И только затем -gcflags=-m, который объясняет, почему компилятор решил именно так.

Наоборот не работает. На приличном проекте вывод -gcflags=-m это тысячи строк, и без бенчмарка ты не знаешь, какая из них в горячем пути. Убранная аллокация вне горячего пути даёт ноль выигрыша и стоит читаемости.

// Что помогает, когда путь найден: задать вместимость слайсу заранее, не таскать крупные структуры через интерфейсы, вынести форматирование строк из цикла. Всё остальное - после замера.

allocs/op

аллокаций на одну операцию в бенчмарке

-gcflags=-m

печатает решения анализа при сборке

Как отвечать: «Что такое escape analysis и безопасно ли вернуть адрес локальной переменной?»

Escape analysis это анализ компилятора, который на этапе сборки решает, где разместить значение: на стеке или в куче. Правило одно - переживёт ли значение свой кадр стека. Не переживёт, значит остаётся на стеке, а это дёшево: выделение там сдвиг указателя, освобождение бесплатное. Переживёт, значит уезжает в кучу, и дальше за ним следит сборщик. Поэтому вернуть адрес локальной переменной в Go безопасно, в отличие от C: повисшего указателя не возникнет, а конструктор вида func New() *T { return &T{} } - обычная идиома. Проверяется решение флагом -gcflags=-m: я так и смотрел, на функции с локальной переменной компилятор печатает moved to heap, на укладке значения в интерфейс - escapes to heap. Вторая строка про аргументы fmt.Println, и это цена боксинга: параметр имеет тип any, ему нужен адрес, поэтому логирование в горячем цикле дороже, чем кажется. Есть тонкость: после инлайна вердикт может смениться на противоположный, кадр становится общим и переживать нечего. Оптимизирую я это только после профиля - сперва бенчмарк с -benchmem и allocs/op, потом уже разбор, что и почему уезжает.

Сильный ответ: механизм сведён к одному правилу, страх из C снят конкретной идиомой, названы инструмент проверки и обе характерные строки вывода, добавлена цена боксинга и оговорка про инлайн. Финал про порядок работы показывает инженера, а не любителя микрооптимизаций.

На чём валят

• −Боятся возвращать адрес локальной переменной по привычке из C.
• −Считают, что new всегда кладёт в кучу, а литерал - на стек. Решает анализ, а не форма записи.
• −Не знают про цену боксинга и логируют через fmt в горячем цикле.
• −Читают -gcflags=-m без строк can inline и удивляются противоречиям в выводе.
• −Оптимизируют аллокации без профиля и теряют читаемость впустую.