В профиле Go-сервиса видно, что при большом числе записей указателей растёт время GC. Как механизм write barrier объясняет этот эффект?
Во время конкурентной фазы маркировки write barrier перехватывает записи указателей, чтобы изменения графа объектов не нарушили корректность GC. Такая защита добавляет проверки, операции маркировки и иногда постановку объектов в очереди на обработку, поэтому большое число записей указателей увеличивает CPU-затраты сборщика и приложения.
Барьер нужен как плата за уменьшение длительных остановок мира: приложение продолжает работать во время маркировки, но часть работы GC выполняется непосредственно при изменении ссылок.
Полностью остановочная сборка мусора упрощает анализ памяти, но при больших кучах может давать неприемлемые паузы. Конкурентная маркировка позволяет сборщику работать одновременно с пользовательскими горутинами, однако теперь граф объектов меняется прямо во время его обхода.
Write barrier появился как механизм координации между мутатором и GC. Он сохраняет корректность маркировки, не требуя останавливать все горутины на весь этап обхода памяти.
Представим, что GC уже просканировал объект и считает его чёрным, а новый объект ещё не просканирован и считается белым. Если приложение запишет ссылку из чёрного объекта на белый и сборщик не заметит эту запись, белый объект может быть ошибочно признан недостижимым.
Ошибка такого рода опаснее обычного замедления: живой объект может быть освобождён, а последующее обращение к нему приведёт к повреждению памяти. Поэтому записи указателей во время маркировки требуют дополнительной обработки.
Компилятор Go вставляет write barrier в места, где программа записывает указатели в память. Во время активной маркировки барьер проверяет фазу GC и выполняет необходимые действия, например помечает связанный объект или передаёт дополнительную работу сборщику. Конкретные детали зависят от внутренней реализации и текущей фазы GC, но общий смысл один: изменения ссылочного графа не должны быть потеряны.
У записи указателя появляется дополнительная стоимость: условная проверка, возможные атомарные операции, обращение к структурам маркировки и обработка дополнительной работы. При высокой частоте таких записей это увеличивает загрузку CPU, давление на кэш и объём работы маркировщиков; часть работы может выполняться горутинами приложения через механизм содействия GC.
Барьер не делает одинаково дорогими все операции записи. Вне активной маркировки его быстрый путь обычно сводится к проверке состояния GC, а для записей значений без указателей не требуется отслеживать связи в графе объектов. Поэтому важны не только размер кучи и число аллокаций, но и интенсивность изменения указательных полей.
Снижение стоимости обычно ищут в уменьшении лишних мутаций ссылочного графа: обновляют структуры пакетно, сокращают pointer-heavy представления, не создают промежуточные объекты без необходимости и проверяют профиль до оптимизации. Полностью избегать барьеров ценой отключения или чрезмерного ослабления GC обычно нельзя: это может привести к резкому росту памяти и более тяжёлым циклам сборки.
В сервисе кэш обновлялся на высокой частоте: каждая операция создавала временный объект и устанавливала несколько указателей в общих индексах. Профилирование показывало, что во время маркировки росли CPU-затраты GC, хотя объём живой памяти почти не менялся.
Рассматривались три варианта. Увеличение GOGC уменьшало частоту циклов, но повышало размер кучи и задержку очистки. Остановка обновлений на время сборки снижала конкуренцию за CPU, но была неприемлема для SLA. Перестройка индекса на пакетное обновление и хранение части связей через компактные идентификаторы уменьшала число указательных записей, но усложняла код доступа.
Выбрали третий вариант для наиболее горячего пути, предварительно подтвердив профильными измерениями, что именно мутации ссылок дают существенную долю затрат. В результате снизилась работа, выполняемая на write barrier, а не просто количество вызовов GC; компромиссом стали дополнительные преобразования идентификаторов и более сложное обновление индекса.
Вопрос: Делает ли write barrier каждую запись указателя одинаково дорогой?
Ответ: Нет. Важны фаза GC, тип записи, место назначения и оптимизации компилятора. Когда маркировка неактивна, обычно выполняется дешёвая проверка состояния, а во время конкурентной маркировки может добавляться реальная работа по поддержанию корректности графа.
Поэтому нельзя делать вывод только по числу присваиваний указателей. Нужно сопоставлять профиль CPU, фазу GC и характер изменяемых структур.
Вопрос: Удерживает ли write barrier старый объект в памяти до следующего цикла GC?
Ответ: Сам по себе барьер не предназначен для продления времени жизни объекта. Он сообщает сборщику об изменении ссылок или обеспечивает необходимую маркировку, но окончательная достижимость определяется корнями и текущим графом объектов.
Объект может оставаться в памяти после потери ссылок из-за того, что текущий цикл ещё не завершил sweep, однако это обычное следствие работы GC, а не гарантия, создаваемая write barrier.
Вопрос: Почему изменение поля-указателя может быть дороже записи обычного числового поля?
Ответ: Числовое поле не изменяет граф ссылок, поэтому GC не требуется отслеживать его как связь между объектами. Запись указателя потенциально меняет достижимость объектов и во время маркировки должна проходить через механизм барьера.
Это не означает, что любая числовая запись бесплатна: она тоже потребляет CPU и пропускную способность памяти. Разница состоит именно в дополнительной работе по поддержанию корректного состояния конкурентной маркировки.