![\"Пулы](\"/assets/illustrations/gc-small-pools.svg\")
Программа на D начинает отвечать рывками. В логах появляются редкие длинные паузы, RSS растёт, а команда сразу обвиняет сборщик мусора. Цена такой ошибки высока: можно отключить GC и получить неконтролируемый рост памяти, либо начать вручную освобождать объекты там, где проблема возникла в аллокаторе, жизненном цикле данных или профиле нагрузки.
\nТезис статьи простой: GC нельзя оценивать по одному симптому. Сначала разделите время приложения, время выделения памяти и время сбора. Затем посмотрите, какие объекты живут долго, а какие создаются ради одной итерации. Устройство сборщика объясняет, почему эти измерения важнее совета «вызови GC.collect».
Сборщик D освобождает память объектов, до которых программа больше не может добраться. Он находит корни, проходит по памяти и отмечает возможные ссылки. Цена зависит от реализации runtime, размера кучи, числа объектов и объёма сканируемой памяти.
\nРазбор DConf 2017 описывает GC как набор пулов. Пул содержит отображённую память и метаданные: биты занятости, биты маркировки, списки свободных блоков и сведения, позволяющие восстановить начало объекта по адресу внутри него. Сборщик разделяет пулы малых и больших объектов. Это ускоряет обычные выделения, но создаёт дополнительные пути поиска.
\nДля малого объекта размер округляется до класса. В историческом описании использовались классы 16, 32, 64, 128, 256, 512, 1024 и 2048 байт. Если точный размер не совпадает с классом, часть блока остаётся неиспользованной. Это внутренняя фрагментация. При неудачном распределении размеров она увеличивает объём памяти без увеличения полезных данных.
\nПулу нужно также найти объект по внутреннему указателю. В описанной архитектуре сначала проверяется диапазон адресов, затем выбирается пул, затем по таблице страниц определяется класс размера. Для большого объекта дополнительно находится начало диапазона, потому что указатель может указывать не на первый байт.
\nЕсли пулов много, поиск по ним становится частью маркировки. Пусть GC проверяет N возможных значений, а выбор пула занимает log(P), где P — число пулов. Тогда один проход получает множитель N × log(P). Это не доказывает, что любая такая реализация медленная в production. Это показывает, что в профиле нужно искать не только вызов GC, но и работу внутри маркировки.
\nСборку удобно рассматривать как четыре фазы: подготовка, маркировка, очистка и возврат свободной памяти. Одинаковая по длительности пауза может иметь разные причины, потому что фазы используют разные структуры данных.
\nНа подготовке runtime готовит сведения для следующего цикла. Если свободные блоки и биты занятости нужно заново сопоставить с битами маркировки, сборщик проходит по спискам и метаданным до основной работы. Такой проход попадает в stop-the-world и заметен, когда свободные списки состоят из множества разрозненных элементов.
\nМаркировка сканирует корни и найденные области. Консервативный сборщик не всегда может доказать, что машинное слово является указателем. Он сохраняет возможные ссылки, чтобы не удалить живой объект. Обратная сторона — ложные указатели удерживают память дольше, а сканирование требует дополнительных проверок.
\nДля каждого кандидата маркировка может проверить диапазон кучи, найти пул, определить тип блока, восстановить начало объекта, проверить бит маркировки и добавить область в следующий проход. Смешивание сканируемой и несканируемой памяти в одном пуле добавляет проверку таблицы. Разделение пулов по этим свойствам могло бы сократить критический путь, но это изменение дизайна runtime.
\nОчистка вызывает финализаторы, если они есть, и отмечает освобождённые блоки. Затем списки свободных блоков могут быть перестроены. Если это требует линейного прохода по пулам, время зависит от резервов и количества страниц, а не только от числа недостижимых объектов.
\nБольшие выделения образуют отдельный риск. Для объекта размером в десятки или сотни мегабайт постраничные метаданные могут оказаться дорогими относительно самого объекта. Такой объект нельзя оценивать тем же профилем, что и поток короткоживущих строк.
\nНиже приведён минимальный пример для локального эксперимента. Он не сообщает production-результат и не доказывает, что участок требует ручного управления GC. Его задача — зафиксировать границу batch и сравнить наблюдения до и после изменения кода.
\nimport core.memory : GC;\nimport std.stdio : writeln;\n\nvoid processBatch(const int[] values) {\n auto before = GC.stats();\n foreach (value; values) {\n auto squared = value * value;\n writeln(squared);\n }\n auto after = GC.stats();\n writeln(\"allocated: \", after.usedSize - before.usedSize);\n}\n\n// GC.collect() проверяем на границе batch,\n// а не вызываем в каждой итерации.В этом фрагменте нет искусственной аллокации на каждой итерации. Поэтому он не служит тестом производительности GC. Для полезного эксперимента возьмите реальную функцию, запишите входной набор, режим сборки и число повторов, а затем сравните время, аллокации и паузы.
\nОтключение GC меняет условия эксперимента. Память, которую программа перестала использовать, не вернётся автоматически, пока GC выключен. Если участок создаёт больше временных данных, чем предполагалось, RSS растёт даже при хорошей скорости. Поэтому GC.disable допустим только на короткой измеримой границе с гарантированным возвратом к обычному режиму.
| Симптом | Возможная причина | Проверка | Действие |
|---|---|---|---|
| Редкая длинная пауза | Полная маркировка или перестройка свободных списков | Снять несколько профилей и отделить время GC | Найти фазу и размер кучи; не отключать GC по одному событию |
| Heap растёт между циклами | Долгоживущие ссылки, кэш или ложные указатели | Сравнить удерживаемые объекты и граф ссылок | Убрать ненужные ссылки, ограничить кэш и повторить замер |
| Частые сборки | Много мелких временных объектов | Посчитать аллокации в горячем цикле и размеры классов | Переиспользовать буферы и сократить промежуточные значения |
| Пауза после batch | Отложенная работа GC на границе набора данных | Сравнить профиль с явным сбором в конце batch | Оставить collect только при повторяемом улучшении |
| Большой RSS после крупного объекта | Фрагментация или дорогие метаданные пула | Измерить размер объекта, резерв и возврат страниц | Изменить модель буфера или способ крупных выделений |
GC.collect только на границе операции. Сравните распределение задержек, а не только среднее.Разбор DConf 2017 описывает устройство и направления улучшения исторического GC. Детали зависят от версии компилятора и runtime. Нельзя переносить утверждение о конкретном поиске пула или фазе паузы на современную сборку без чтения исходников и профиля.
\nКонсервативная маркировка объясняет риск ложных указателей, но не позволяет по одному росту памяти доказать их наличие. Внутреннюю фрагментацию также нельзя вычислить по одному RSS: нужны классы выделений, резерв и фактически занятые байты.
\nУчебный код не моделирует сетевой сервис, конкурентные потоки, большие объекты и реальные SLA. Он нужен только для воспроизводимого сравнения двух локальных вариантов. Production-результат появляется после профиля на реальной нагрузке, контрольной группе и сохранённом пороге.
\nДиагностика готова, если для исходной паузы записаны фаза GC, размер кучи, число аллокаций и повторяемый вход; изменение улучшает выбранный порог на release-профиле; RSS не растёт за установленный лимит; а ручное управление имеет условие возврата. Если эти данные не собраны, вывод «виноват сборщик» остаётся гипотезой.
\n