-gcflags=-m и чего не делать

Как увидеть решения

$ go build -gcflags=-m ./...

Флаг печатает решения escape analysis вместе с решениями об инлайнинге. Ключевые сообщения:

./main.go:11:10: &record{...} escapes to heap
./main.go:17:5: moved to heap: n
./main.go:29:17: u escapes to heap

escapes to heap — значение ушло в кучу; moved to heap — захваченная замыканием переменная; does not escape — осталось на стеке, и его хочется видеть в горячем коде.

Две оговорки о чтении

Escape analysis выполняется после инлайнинга, поэтому с -gcflags=-m -l (отключить инлайнинг) картина может измениться — это тот же анализ, но в другом контексте. И escapes to heap — решение анализа, а не факт аллокации: указатель, боксующийся в интерфейс, ничего не аллоцирует, хотя сообщение может появиться. Точную цифру покажет бенчмарк с -benchmem. Для деталей есть -gcflags=-m=2 — граф потока: из какой точки значение утекает и куда.

Чего делать не надо

Escape analysis — оптимизация компилятора, а не гарантия языка. Две логически одинаковые программы могут различаться по аллокациям между версиями Go: анализ регулярно улучшают, и код, сбегавший в кучу в одной версии, в следующей может остаться на стеке. Поэтому не пиши код «под escape analysis»: трюки ради does not escape — ломкие, нечитаемые и перестают работать после обновления тулчейна. Нормальная стратегия — идиоматичный код, а -gcflags=-m — диагностика на случай, когда профиль показывает аллокации там, где их не ждали.