Разбор последствий: почему две структуры одинакового размера могут по-разному влиять на паузы и загрузку GC?
Раз structures одинакового размера могут создавать разную нагрузку на GC, если одна содержит много полей-указателей, а другая — преимущественно скалярные данные. Сборщику нужно просматривать указательные поля и переходить по найденным ссылкам, тогда как память без указателей можно не сканировать на наличие ссылок.
Поэтому на стоимость сборки влияют не только объём живой памяти и число аллокаций, но и плотность указателей, граф достижимости и количество объектов, которые требуется обработать.
Go использует трассирующий конкурентный сборщик мусора: он определяет живые объекты, начиная от корней, и освобождает недостижимые. Для работы с объектами рантайму необходимо знать, какие участки памяти могут содержать указатели.
Эта информация позволяет применять разные стратегии к указательной и неуказательной памяти. Поддержка объектов без указателей снижает объём сканирования и особенно важна для массивов байтов, числовых буферов и других больших блоков данных.
Предположим, приложение хранит одинаковый объём данных в двух представлениях. В первом случае это компактные записи со скалярами, во втором — записи с несколькими ссылочными полями на другие объекты.
При большом количестве живых объектов второй вариант может увеличить время маркировки: GC должен просмотреть больше указателей, проверить их значения и потенциально посетить больше объектов. Неверно оценивать такую нагрузку только по числу байтов или считать, что одинаковый размер структур гарантирует одинаковую производительность.
Компилятор формирует для типов информацию о расположении указателей. При маркировке GC использует её, чтобы сканировать только релевантные области объекта. Указательная память требует проверки ссылок и обхода графа объектов, а неуказательная память не содержит ссылок, по которым может продолжаться обход.
Разница особенно заметна при большом числе небольших объектов. У структуры с указателями есть не только собственный размер: её ссылки могут удерживать дополнительные объекты живыми, увеличивая размер графа и объём работы маркировщика. Если эти объекты разрознены в памяти, дополнительно ухудшается локальность доступа к памяти.
Это не означает, что любой указатель автоматически делает программу медленной. Важны фактическая доля живых объектов, частота сборок, размер графа, распределение времени жизни и профиль доступа. Указатели могут уменьшить копирование или сделать модель данных удобнее, поэтому отказ от них оправдан только при подтверждённой нагрузке.
Память без указателей тоже учитывается при управлении размером кучи и может привести к запуску GC. Однако после начала сборки её содержимое не требуется обходить как граф ссылок. Поэтому отказ от лишних ссылочных полей обычно уменьшает именно стоимость сканирования и маркировки, но не отменяет расходы на выделение памяти, инициализацию и освобождение.
Сервис обрабатывает большой поток сообщений. Профилирование показывает, что сообщения после разбора долго живут до конца пакетной операции, а каждая запись содержит несколько указателей на небольшие вспомогательные объекты. Размер полезных данных умеренный, но маркировка занимает заметную долю CPU.
Рассматривались три варианта. Увеличение GOGC могло снизить частоту сборок, но повысило бы допустимый объём кучи и потребление памяти. Переход на пул объектов мог уменьшить число аллокаций, но усложнить управление временем жизни и не устранить обход большого графа. Уплотнение записи и хранение небольших значений непосредственно в ней уменьшало число указателей и объектов, но требовало изменить формат данных.
Выбрали третий вариант для горячего пути, а пул применили только к действительно переиспользуемым буферам. В результате сократилось число объектов и указательных связей, поэтому уменьшилась работа маркировки; при этом решение проверили нагрузочным тестом, поскольку чрезмерное уплотнение могло увеличить копирование и усложнить код.
Нет. Замена может уменьшить число объектов и указательных связей, но увеличивает размер самих структур и стоимость их копирования. Если структуры часто копируются или редко живут достаточно долго, выигрыш от более дешёвого сканирования может быть меньше новых расходов. Решение нужно подтверждать профилированием аллокаций, CPU и задержек.
Да, наличие указательного поля влияет на схему сканирования типа: GC должен рассматривать соответствующую область как потенциально содержащую ссылку. При этом конкретное значение nil не ведёт к дальнейшему обходу объекта, поэтому фактическая стоимость зависит от содержимого и числа ненулевых ссылок. Поле, которое концептуально всегда пусто, может быть кандидатом для изменения модели данных, но это следует оценивать вместе с размером и выравниванием структуры.
Маркировка работает прежде всего с живым графом: GC должен просмотреть указательные поля живых объектов, чтобы доказать достижимость их потомков. Поэтому недостижимые объекты не отменяют стоимость обхода большого живого графа. Дополнительно разрозненные объекты могут ухудшать кэш-локальность, а многочисленные связи усложняют поддержание и обработку графа во время конкурентной сборки.