Monomorphic, polymorphic, megamorphic — и stub cache

Полная машина состояний, а не три слова

Слот load IC проходит больше состояний, чем намекал обзор. Полная лестница, односторонняя к megamorphic:

• uninitialized — слот никогда не выполнялся.
• premonomorphic — состояние V8 «видел раз, жду подтверждения». Самое первое выполнение часто записывает map здесь, ещё не выпуская специализированный handler, так что одноразовый путь не платит за IC, который никогда не переиспользует. Второе попадание с тем же map повышает до monomorphic.
• monomorphic — ровно один map. Слот — это {map, handler} (урок 04). При попадании: загрузить map, сравнить, применить handler — пара инструкций. Это целевое состояние.
• polymorphic — от 2 до 4 map. Слот становится маленьким списком пар {map, handler}. Load сканирует список (несколько сравнений) и применяет совпавший handler. Всё ещё быстро, но цепочка ветвлений растёт с каждой формой.
• megamorphic — 5 или более map. V8 полностью прекращает отслеживать map в этой точке. Слот помечается megamorphic, и поиски проваливаются в megamorphic stub cache.

Megamorphic stub cache: хеш-таблица на весь процесс

Это часть, о которой обзор никогда не упоминает. Когда точка megamorphic, V8 не делает свежий поиск свойства на каждый доступ. Вместо этого он обращается к единственной, глобальной (пер-изолят) хеш-таблице — megamorphic stub cache — с ключом (map, имя свойства), хранящей handler. Доступ становится:

1. Вычислить хеш из map объекта и имени свойства.
2. Зондировать stub cache (это маленькая, фиксированного размера таблица с открытой адресацией — первичная и вторичная таблицы).
3. При попадании использовать закэшированный handler. При промахе сделать полный рантайм-поиск и вставить результат.

Так что megamorphic-точка — это хеш-зонд плюс вероятное применение handler — намного медленнее, чем monomorphic-сравнение-и-load (десятки-низкие сотни циклов против ~1), и поскольку таблица общая и фиксированного размера, разные megamorphic-точки вытесняют записи друг друга. Стоимость не только в зонде; она в том, что точку больше нельзя специализировать.

Почему megamorphic враждебен к JIT, а не просто медленнее

Более глубокая стоимость — что это делает с TurboFan. Monomorphic- или низко-polymorphic-точка даёт оптимизатору маленький, известный набор форм, так что он может заинлайнить load поля (или весь метод) и защититься дешёвой проверкой map. Megamorphic-точка не даёт TurboFan никакой пригодной информации о форме — feedback — это «что угодно» — так что TurboFan должен выпустить общий вызов к машинерии stub cache и не может заинлайнить доступ или что-либо достижимое через него. Один megamorphic-доступ к свойству в горячем заинлайненном методе поэтому может заблокировать целую цепочку оптимизаций, стоя намного больше, чем один лишь хеш-зонд на доступ.

Prototype-chain IC и validity cell

Многие реальные load’ы находят свойство не на самом объекте, а на его прототипе (методы живут на Class.prototype). Prototype-chain IC кэширует «свойство на N уровней вверх по цепочке, по этому смещению» — но это безопасно лишь пока цепочка прототипов не изменилась. V8 охраняет это validity cell: маленькой ячейкой кучи, разделяемой map’ами, зависящими от данного прототипа, которая «валидна», пока кто-то не мутирует тот прототип (добавит/удалит свойство на нём или переприсвоит его). Быстрый путь prototype IC: проверь map, проверь, что validity cell всё ещё валидна, затем грузи.

Зубы: мутация прототипа после того, как объекты существуют, инвалидирует validity cell, что деоптимизирует каждый IC и каждую скомпилированную TurboFan’ом функцию, опиравшуюся на неё. Поэтому monkey-patching Array.prototype или присваивание SomeClass.prototype.method во время работы (после того как горячие пути разогрелись) может вызвать внезапное, ощущаемое как глобальное замедление — вы задели validity cell, которой доверяли тысячи точек.