Orinoco GC: параллельный scavenger, конкурентная разметка и барьеры записи

Node.js-сервис нормально работает неделю, затем каждые 60 секунд появляется 5мс пауза в латентности p99. Код приложения не менялся. Цикл GC пересёк порог старого поколения. Понимание Orinoco — это разница между угадыванием и диагностикой.

Структура кучи

Куча V8 разделена на два поколения:

• Молодое поколение — только что выделенные объекты, обычно 1–8 МБ. Собирается часто (малый GC).
• Старое поколение — долгоживущие объекты, может быть сотни МБ. Собирается редко (крупный GC).

Объекты начинают в молодом поколении. Пережившие два малых GC продвигаются в старое. Этот генерационный дизайн использует наблюдение, что большинство объектов умирают молодыми — малый GC может быть быстрым, поскольку живое множество мало.

Малый GC: параллельный Scavenger

Scavenger использует копирующий сборщик с двумя полупространствами:

1. From-space содержит живые объекты; to-space пусто.
2. При сборке V8 обходит корни (стек, глобальные, регистры), копирует достижимые молодые объекты в to-space, обновляет указатели.
3. Мёртвые объекты брошены в from-space.
4. Пережившие два малых GC продвигаются в старое поколение.

Scavenger параллелен с первой фазы Orinoco (V8 6.2, 2017): несколько рабочих потоков делят работу через динамическое воровство задач (work-stealing). Паузы основного потока ~1мс, поскольку живое множество молодого поколения мало, а параллелизм держит wall-clock время низким.

Крупный GC: Mark-Compact с конкурентной разметкой

Сборка старого поколения трассирует все живые объекты, подметает мёртвые и уплотняет выжившие для снижения фрагментации. До Orinoco это была операция stop-the-world длительностью сотни мс на больших кучах.

Ключевое нововведение Orinoco: конкурентная разметка — фоновый поток обходит кучу, пока JavaScript выполняется на основном потоке. Основной поток платит краткую финальную паузу разметки (однозначные мс) плюс фазу подметания/уплотнения (параллельная по рабочим потокам, но всё ещё блокирующая). Результат: пауза основного потока снижена ~на 50% на WebGL-нагрузках.

Барьеры записи

Чтобы конкурентная разметка была корректной, пока JS одновременно мутирует кучу, V8 использует барьеры записи: небольшой код, генерируемый при каждой записи свойства, которая может пересечь от чёрного (уже помеченного) объекта к белому (ещё не посещённому).

V8 использует семантику snapshot-at-the-beginning (Юаса): когда основной поток перезаписывает ссылку на белый объект, барьер затемняет исходный (перезаписанный) референт в серый, чтобы маркер всё равно его посетил. Это сохраняет инвариант «каждый объект, достижимый при начале разметки, будет посещён», даже если основной поток опережает. Барьер записи стоит ~3–5 тактов на запись; V8 значительно вкладывает в то, чтобы держать его дешёвым.

Современный V8 использует три-цветную разметку (белый/серый/чёрный) с семантикой snapshot-at-the-beginning и гибридным конкурентным + инкрементным планированием. Инкрементная разметка амортизирует работу GC по выполнению JS без наблюдаемой единой паузы.