Поколенческий GC и Scavenger

Поколенческая гипотеза

Урок browser/03-v8-internals/05-gc-orinoco даёт обзор; здесь мы вскрываем механику Scavenger’а.

Эмпирический фундамент каждого продакшен-GC — поколенческая гипотеза (generational hypothesis): большинство объектов умирает молодыми. Распределение времён жизни аллокаций резко бимодально — подавляющее большинство недолговечны (временные значения запроса, промежуточные строки, React-элементы на рендер) и становятся недостижимыми за несколько миллисекунд, тогда как небольшое меньшинство (кэши, граф модулей, пулы соединений) живёт весь процесс. Почти ничто не умирает посередине.

V8 эксплуатирует это, деля кучу по возрасту:

• New space (young generation) — где рождается каждый обычный объект. Маленький: бюджет, растущий по требованию примерно до 1–8 МБ на isolate (настраивается через --max-semi-space-size). Собирается часто и дёшево minor GC.
• Old space (old generation) — долгоживущие выжившие. Может быть от сотен МБ до гигабайт (--max-old-space-size). Собирается нечасто major GC (следующий урок).

Поскольку new space мал и почти всё в нём мертво к моменту сборки, minor GC касается очень малого объёма живых данных — в этом вся выгода.

New space — это два semi-space; аллокация — это bump pointer

New space физически состоит из двух равных половин, называемых semi-space: to-space (активная) и from-space (простаивающая). Аллокация в to-space — самая дешёвая операция в движке — bump-pointer allocator: держим указатель на следующий свободный байт, выдаём его, продвигаем указатель на размер объекта. Никакого поиска по free-list, никакой фрагментации — просто сложение и проверка границ.

// Концептуально, каждый `new`/объектный литерал делает:
//   if (top + size > limit) triggerScavenge();
//   addr = top;
//   top += size;          // продвижение указателя (bump)
//   return addr;
const point = { x: 1, y: 2 };   // аллокация bump-pointer'ом в to-space

Когда bump pointer достигает предела (to-space заполнен), срабатывает Scavenge (minor GC).

Scavenger: копирующий алгоритм Чейни

Scavenger — это копирующий сборщик (copying collector), исполняющий алгоритм Чейни. Ключевая инверсия по сравнению с mark-sweep: он вообще не смотрит на мёртвые объекты. Он копирует живые и оптом бросает остальное.

1. Flip. Роли меняются: текущая to-space становится from-space, пустая половина — новой to-space.
2. Эвакуация корней. Сканируем корни (стек, глобальные, handle) плюс remembered set указателей old→new (см. урок 04 — old space может ссылаться на молодые объекты, а мы old space не сканируем). Копируем каждый живой молодой объект, на который ссылаются, из from-space в to-space, оставляя в старом слоте forwarding pointer.
3. Скан Чейни. Обходим только что скопированные объекты в to-space «вширь» как рабочую очередь; для каждого копируем любые объекты from-space, на которые он ссылается (или идём по существующему forwarding pointer, если уже скопирован), обновляя указатель на новое место. Это продолжается, пока указатель скана не догонит указатель аллокации — очередь пуста.
4. Освобождение неявно. Всё, что не скопировано, просто остаётся в from-space, которая теперь одним махом объявляется пустой. Освобождение мёртвых объектов не стоит ничего — их никогда не посещают.

Работа пропорциональна живому множеству, а не аллоцированному. Пока поколенческая гипотеза держится, живое множество крошечно, поэтому Scavenge быстр.

Promotion: выжить — значит постареть

Объект, переживший Scavenge, ещё не признаётся долгоживущим; его копируют в to-space и дают ещё один шанс. Если он переживает второй Scavenge, V8 заключает, что он, вероятно, долгоживущий, и повышает его (promotion): копирует в old space, а не обратно в semi-space. (V8 также повышает раньше под давлением «промежуточного» поколения и аллоцирует очень большие объекты сразу в old/large-object space, но «выжить дважды → повысить» — это модель, которую стоит держать в голове.)

Promotion — причина, по которой Scavenge может оставить new space почти пустым: временные объекты никогда не копировались (мертвы), а немногие настоящие выжившие окончили в old space. New space остаётся маленьким, и следующий Scavenge остаётся дешёвым.

Orinoco: делаем параллельным

Orinoco — зонтичное имя современного GC-проекта V8: набора техник, превращающих stop-the-world сборщик в по большей части конкурентный, параллельный и инкрементальный. Конкретно для Scavenger Orinoco сделал его параллельным: несколько вспомогательных потоков делят работу копирования через динамический work-stealing, так что время паузы по стенным часам падает, хотя сырой работы становится больше. Поскольку new space мал, minor-паузы укладываются в диапазон от долей миллисекунды до единиц миллисекунд — достаточно коротко, чтобы комфортно поместиться в кадр анимации 16,6 мс. Более тяжёлые конкурентность и инкрементальность относятся в основном к major GC — это следующие два урока.