Обратная связь о типах: топливо для оптимизатора

Почему оптимизатор слеп без обратной связи

У JavaScript нет статических типов, которым движок мог бы доверять. В точке, где компилируется function add(a, b) { return a + b; }, движок не может доказать, что a — число: это может быть строка, объект с valueOf, BigInt. Наивно скомпилированный + поэтому обязан обработать каждый случай: проверить теги, ветвиться на строку-против-числа-против-объекта, возможно вызвать пользовательский valueOf, забоксить результат. Этот обобщённый путь корректен, но медленный.

Выход — спекуляция: предположить те типы, которые вы реально наблюдали, выпустить быстрый код ровно под них и защитить его дешёвым guard, который откатывается, если предположение нарушится (урок 04). Но спекуляции нужны улики — и улики приходят от единственного яруса, который исполняет каждую операцию, наблюдая за её операндами: от Ignition, интерпретатора. Пока Ignition работает, он записывает то, что видит в каждом «интересном» месте. Эта запись и есть feedback vector (вектор обратной связи).

Feedback vector: структура и владение

Feedback vector — это массив фиксированного размера, выделенный в куче GC. Ключевая деталь, в которой ошибаются, — это кто им владеет. Байт-код и раскладка слотов обратной связи разделяются: они живут в SharedFunctionInfo (SFI) функции — дедуплицированной записи движка «код этой функции», одна на определение в исходнике. Но сам вектор обратной связи — массив, хранящий наблюдённые данные, — выделяется на каждое замыкание. Два замыкания, созданные из одного исходника функции, разделяют байт-код и раскладку слотов, но у каждого свой feedback vector, так что их рантайм-наблюдения не загрязняют друг друга.

Каждый слот соответствует одному IC-сайту (inline cache) в байт-коде — месту, где тип операндов важен:

• Доступ к свойству (obj.x, obj.x = v) — записывает карту (hidden class) увиденного объекта плюс handler, описывающий, как загрузить/сохранить на этой карте.
• Вызовы (fn(), obj.method()) — записывает наблюдённую цель(и) вызова, что позволяет инлайнинг.
• Бинарные операции (a + b, a < b) — записывает решётку типов (type lattice) операндов: были они всегда Smi (малое целое)? Smi-или-HeapNumber? String? Any?
• Доступ к элементу (arr[i]) — записывает elements kind (packed Smi, packed double, holey, dictionary).

Решётка примитивных типов

Для арифметики обратная связь — это не просто «число». V8 отслеживает типы операндов на небольшой решётке (lattice), которую монотонно расширяет по мере того, как видит больше случаев. Полезная модель для слота +:

None  ->  SignedSmall (Smi)  ->  Number (Smi или HeapNumber)  ->  NumberOrOddball  ->  Any
                       \-> String (если появляется строковый операнд) -> Any

Каждое новое наблюдение может двигать слот только вверх по решётке (расширять), никогда не сужать. Слот, который видел только малые целые, остаётся на SignedSmall, и TurboFan может выпустить 32-битное целочисленное сложение, защищённое единственной проверкой «это Smi». Как только этот слот впервые увидит значение, переполняющее диапазон Smi, он расширяется до Number, и следующая оптимизация выпустит float64-арифметику. Если он когда-либо увидит строку, он расширяется к Any, и арифметика откатывается к полностью обобщённой процедуре. Это монотонное расширение — ровно причина, почему смешивание типов так разъедает: одно значение не того типа навсегда загрязняет слот на всё время жизни этого feedback vector.

Мусор на входе — обобщённое на выходе

Вот практический вопрос: если вы кормите горячую функцию пятью разными формами объектов в первых двенадцати вызовах, что видит оптимизатор, когда наконец компилирует? Оптимизатор хорош ровно настолько, насколько хороша обратная связь. Для любого IC-слота (inline cache — встроенный кеш типа) важны три состояния:

• Мономорфный (monomorphic) — наблюдена одна карта / один стабильный тип. Оптимизатор специализируется жёстко: прямая загрузка по смещению, инлайн вызова, целочисленное сложение. Самый быстрый.
• Полиморфный (polymorphic) — небольшая горстка (предел V8 — 4) карт/типов. Оптимизатор всё ещё может инлайнить с предварительной проверкой карты, ветвящейся между известными случаями. Медленнее, но всё ещё оптимизированно.
• Мегаморфный (megamorphic) — больше предела. Слот помечается мегаморфным sentinel; оптимизатор сдаётся со специализацией и выпускает обобщённую диспетчеризацию (рантайм-поиск). Он может вообще отказаться оптимизировать окружающую функцию.

Вместе эти три состояния описывают всю игру: разогрев одной формой даёт быстрый путь, две-три формы сохраняют оптимизацию, а больше четырёх — навсегда переводят слот в обобщённую диспетчеризацию.

Практическое правило, вытекающее отсюда: разогревайте функцию согласованными типами до того, как она повысит ярус. Если горячая функция в основном будет обрабатывать целые, не давайте первой дюжине вызовов кормить её строками; если место вызова в основном будет получать одну форму объекта, не пускайте через него пять форм. Feedback vector заполняется во время интерпретируемой фазы, и какие решётка и набор карт он накопит — ровно то, на чём оптимизатор сможет (или не сможет) специализироваться.