Write barriers: цена инкрементального и поколенческого GC

Почему запись не бесплатна

Прошлые два урока оставили два долга по корректности, оба порождённые одним и тем же — указателем, изменённым между сборками или во время них:

1. Поколенческий долг. Minor GC сканирует только young space (плюс корни), потому что сканировать гигабайты old space при каждом Scavenge уничтожило бы весь смысл поколенческого GC. Но старые объекты могут держать ссылки на молодые (oldArray.push(youngObj)). Если бы V8 их игнорировал, он освободил бы молодой объект, на который old space всё ещё ссылается.
2. Долг разметки. Конкурентная/инкрементальная разметка даёт JS изменять граф посреди трассировки. Запись может заставить чёрный (просканированный) объект указать на белый (недостигнутый), нарушив трёхцветный инвариант, так что маркер завершится, не посетив живой объект, и sweep его соберёт.

Write barrier — это небольшой кусок кода, который компилятор выпускает вокруг почти каждой записи указателя в объект кучи. Он выполняется в момент obj.field = ptr и делает любой учёт, нужный, чтобы оба вопроса оставались закрыты. Один барьер — две работы.

Работа 1: поколенческий барьер и remembered set

Чтобы не сканировать old space на minor GC, V8 поддерживает remembered set (реализованный через store buffer, позже обрабатываемый в наборы слотов по страницам): запись каждого слота в old space, держащего указатель в young space. Когда вы пишете oldObj.field = youngObj, поколенческий write barrier замечает, что запись пересекает old→young, и записывает этот слот.

При следующем Scavenge V8 трактует remembered set как дополнительные корни: он сканирует эти записанные слоты, чтобы найти молодые объекты, удерживаемые живыми ссылками old space, без обхода old space вообще. После того как Scavenge обновляет адреса перемещённых молодых объектов, именно remembered set позволяет починить указатели old space.

const cache = [];          // promoted to old space over time
function handle(req) {
  const entry = { req };   // young
  cache.push(entry);       // OLD-массив теперь ссылается на YOUNG-запись
  //                          ^ барьер записи поколений фиксирует этот слот
}

Барьер срабатывает только для направления old→young. Записи young→young и young→old неинтересны minor GC (young всё равно полностью сканируется; old→? — забота major GC), поэтому V8 убирает барьер в этих случаях.

Работа 2: барьер инкрементальной разметки (стиль Дейкстры)

Во время конкурентной разметки тот же хук записи защищает трёхцветный инвариант. V8 использует insertion-барьер в стиле Дейкстры: когда мутатор записывает указатель на white-объект в любой объект во время разметки, барьер серит белую цель (кладёт её в marking worklist). Это гарантирует, что маркер в итоге её просканирует, поэтому её нельзя оставить белой и ошибочно собрать. (Классическая альтернатива — Yuasa snapshot-at-the-beginning барьер, серящий перезаписываемого старого референта; дизайн V8 использует insertion в стиле Дейкстры для конкурентного маркера. В любом случае цель идентична: ни один живой объект не ускользает от трассировки.)

Поскольку обе работы запускаются одним событием — записью указателя в слот кучи — V8 сливает их в единый путь барьера, проверяющий нужные условия (активна ли разметка? пересекает ли запись old→young?) и делающий минимум работы.

Почему записи Smi пропускают барьер

Барьер существует только для отслеживания указателей между объектами кучи. Smi (small integer — 31-битное целое в 64-битном V8) — это не указатель: он закодирован прямо внутри tagged-значения с нулевым младшим tag-битом, поэтому он вообще не может ссылаться на объект кучи. Запись Smi в поле — obj.count = 42 — не создаёт межобъектной ссылки, поэтому V8 не выпускает write barrier для неё. То же верно для записи других immediate. Это ещё одна причина, почему различие Smi/HeapNumber из юнита 02 важно для производительности: записи полей с большим числом целых барьерны-свободны, тогда как записи, кладущие указатели на объекты или упакованные double, платят за проверку барьера.

Стоимость и где она кусает

Каждый барьер дёшев по отдельности — несколько инструкций: загрузить метаданные страницы цели или проверить флаг разметки, ветвление, а в медленном случае положить в worklist или store buffer. Назовём это горсткой циклов на запись указателя. Это невидимо в обычном коде. Это становится измеримым на горячих путях с большим числом аллокаций и мутаций: плотные циклы, строящие большие графы объектов, многократно переуказывающие поля или кладущие миллионы ссылок на объекты в долгоживущие контейнеры. Там накладные расходы барьера реальны, и это одна из скрытых стоимостей «просто положить объекты в массив» против работы с типизированными массивами или Smi-кодированными данными.