Быстрые свойства, медленные свойства и slack tracking

Три режима хранения, три скорости

Почему место хранения так важно? Потому что разрыв в 50-100 раз между режимами — это именно тот обрыв, который виден как плоская полка на flame chart CPU, но исчезает при микроаллокациях. Его можно найти только если знаешь, что искать, ещё до профилирования.

DescriptorArray из урока 01 сообщает V8, где живёт поле. Возможных ответов три, в порядке убывания скорости:

1. In-object-свойства. Хранятся встроенно в собственном блоке памяти объекта, сразу за заголовком. Чтение одного — это единственный load по постоянному смещению, самое быстрое из возможного. Число in-object-слотов фиксируется при создании Map.
2. Out-of-object («normal») fast properties. Когда объект перерастает свои in-object-слоты, дальнейшие свойства проливаются в отдельный PropertyArray, на который объект указывает. Они всё ещё быстрые (фиксированное смещение, дружелюбны к IC), но стоят одного лишнего разыменования указателя: загрузить указатель PropertyArray, затем загрузить слот. DescriptorArray записывает индекс со смыслом «это поле в PropertyArray по индексу N».
3. Dictionary mode (медленные свойства). Когда объект становится слишком динамичным — слишком много свойств или любой delete — V8 полностью отказывается от раскладки с фиксированными смещениями и переводит объект в NameDictionary: пер-объектную хеш-таблицу из имени свойства в значение+attributes. Каждый доступ теперь — общий поиск по хешу, примерно 50–100 циклов против ~1 для in-object-load, и inline cache не может помочь. %HasFastProperties(obj) возвращает false.

// d8 --allow-natives-syntax
const a = { p: 1, q: 2, r: 3 };
%HasFastProperties(a);   // true  — in-object, фиксированные смещения
delete a.q;
%HasFastProperties(a);   // false — теперь NameDictionary, навсегда медленный

Slack tracking: V8 подгоняет размер ваших объектов

Вот самонастраивающаяся часть, которую обзор пропустил. Когда вы определяете конструктор или класс, V8 ещё не знает, со сколькими свойствами экземпляры окажутся в итоге — за this.x = ...; this.y = ... могут последовать другие присваивания в методах, вызванных позже. Аллоцировать ровно два in-object-слота заранее значило бы вынудить пролив в PropertyArray в момент появления третьего поля.

Поэтому V8 переаллоцирует: начальный Map конструктора резервирует лишние in-object-слоты (slack) — больше, чем объявляет тело конструктора. По мере создания и работы экземпляров V8 следит за максимальным числом in-object-свойств, которые они реально используют. После того как аллоцировано достаточно экземпляров (фиксированный порог по числу созданий), он завершает slack tracking: подрезает неиспользованные слоты, ужимает instance size в Map и финализирует Map. С этого момента каждый новый экземпляр аллоцируется в подрезанном, точном размере.

Последствия для сеньора:

• Экземпляры разогрева крупнее экземпляров установившегося состояния. Снимок кучи, снятый до завершения slack tracking, завышает размер на объект. Измеряйте после разогрева.
• Map не «финален» сразу. Код, зависящий от стабилизированной формы (и специализации TurboFan), получает её лишь после завершения slack tracking. Микробенчмарки, аллоцирующие горстку объектов, могут видеть другую форму, чем прод в масштабе.
• Добавление свойств вне конструктора после финализации уже не помещается в in-object-область и проливается в PropertyArray (или, если достаточно динамично, в dictionary mode).

Что толкает объект в dictionary mode

Dictionary mode — это обрыв. Вы падаете с него через:

• delete obj.prop на быстром объекте — самая частая причина. V8 не может оставить дырку в раскладке с фиксированными смещениями, поэтому конвертирует весь объект в NameDictionary. Это навсегда: объект никогда не поднимается обратно к fast properties.
• Слишком много свойств, добавленных динамически (порог большой, порядка многих сотен до ~1000+, и зависит от версии), так что это редко настоящий виновник — виновник delete.
• Добавление свойств способом, который ломает дерево переходов — экстремальный churn форм может заставить V8 сдаться и переключиться в dictionary mode, чтобы перестать аллоцировать Map.

Заметьте, const-folding взаимодействует тут: когда поле const (по экземплярам присвоено лишь одно значение), V8 может хранить значение в Map (в дескрипторе), а не в объекте, так что чтения становятся «загрузить константу из Map» — но первое расходящееся присваивание теряет constness (урок 02), и значение переезжает в настоящее поле. Dictionary mode отказывается от всего этого.