Деоптимизация: падение с обрыва

Что такое деопт на самом деле

Провал guard (урок 04) не падает с ошибкой и не выдаёт тихо неверный ответ. Он запускает деоптимизацию: V8 отбрасывает оптимизированный машинный код этой функции и возобновляет исполнение в интерпретаторе Ignition на точном смещении байт-кода, соответствующем месту, где оптимизированный код сдался. Исполнение продолжается корректно, просто медленнее. Оптимизированный код отбрасывается (или помечается невалидным), а функция откатывается на нижний ярус; если она остаётся горячей и её обратная связь стабилизируется, она может быть переоптимизирована позже.

Есть две разновидности, различающиеся тем, что инвалидировало предположение.

Eager deopt (немедленный) происходит синхронно, когда guard падает в рантайме — функция исполняет оптимизированный код, доходит до CheckMaps / CheckSmi / CheckBounds, проверка падает, и управление откатывается прямо там. Триггер локальный: этот вызов увидел значение, которого спекуляция не допускала. В --trace-deopt появляется как DEOPT eager с причиной вроде wrong map или not a Smi.

Lazy deopt (ленивый) происходит, когда предположение инвалидируется извне, а не собственным исполнением функции. Вы переопределяете функцию, которую оптимизированный код встроил, изменяете прототип, от которого он зависел, добавляете свойство к разделяемому объекту или меняете глобал. V8 не может залезть во фрейм, который, возможно, исполняется, поэтому вместо этого он помечает весь зависимый оптимизированный код на деопт при следующем входе — код «лениво» деоптится в следующий раз, когда был бы вызван. В --trace-deopt появляется как DEOPT lazy. Классическая причина — monkey-patching: Array.prototype.map = ... после того, как горячий код был оптимизирован под оригинал.

Трансляция фрейма: как он возвращается чисто

Когда guard падает, V8 должен возобновиться в интерпретаторе — но два фрейма говорят на совершенно разных языках. Сложная часть деопта в том, что оптимизированный фрейм и интерпретаторный фрейм — это совершенно разные раскладки. Оптимизированный код держит значения в машинных регистрах и плотном стек-фрейме, часто в распакованных (unboxed) представлениях (сырой int32, сырой float64). Интерпретатор ожидает значения в собственном регистровом файле («регистры» интерпретатора — это слоты стека) в их тегированной, забоксенной форме. Чтобы возобновиться в интерпретаторе, V8 должен перестроить фрейм интерпретатора из оптимизированного.

Он делает это с помощью метаданных деопта (deopt metadata), записанных на компиляции: для каждой возможной точки деопта TurboFan хранит описание, отображающее каждую живую локацию оптимизированного фрейма (этот машинный регистр держит локальную i, этот слот стека держит total, это распакованный double, который надо перебоксить) на интерпретаторный регистр, которому она принадлежит. В момент деопта deoptimizer читает эти метаданные и выполняет трансляцию фрейма (frame translation) — он выделяет и заполняет свежий фрейм интерпретатора, помещая каждое живое значение туда, где его ожидает Ignition, перебоксивая распакованные значения, затем прыгает в интерпретатор на сохранённое смещение байт-кода. Трансляция одного деопта дёшева, порядка микросекунд.

Цикл деоптимизации: настоящая катастрофа

Один деопт — это нормально: микросекунды учётной работы, затем функция заново разогревается с обратной связью, теперь включающей неожиданный случай, переоптимизируется с более широким предположением и остаётся оптимизированной. Катастрофа — это цикл деоптимизации (deopt-loop): функцию раз за разом кормят формой или типом, который она не может удержать стабильным, так что она оптимизируется, деоптится, переоптимизируется (функция всё ещё горячая, так что V8 продвигает её снова), деоптится опять — бесконечно. Каждый цикл платит трансляцию деопта плюс свежую компиляцию TurboFan (десятки-сотни мс) плюс время, проведённое в медленном ярусе между ними. Функция в цикле деоптимизации на порядки медленнее, чем если бы вы просто отключили оптимизацию через --no-opt.

Когда вы видите в —trace-deopt функцию, мечущуюся между оптимизированным и деоптимизированным состоянием, ищите один из этих паттернов — каждый способ заставить guard падать на повторяющемся значении:

• Переполнение Smi (Smi overflow) — арифметический сайт, оптимизированный на SignedSmall, производит значение за пределами диапазона Smi (больше ~2^30), проваливая CheckSmi каждый раз, когда большое значение повторяется.
• Смена формы / расхождение hidden class — место вызова видит объекты с расходящимися картами; CheckMaps падает. Добавление свойств в разном порядке, условные поля, delete.
• Смена типа поля — поле, оптимизированное как Smi, позже держит строку или объект, так что загрузки, охраняемые представлением поля, деоптятся.
• Чтение arguments в оптимизированных функциях — исторически форсировало деопт или блокировало оптимизацию; современный V8 обрабатывает многие случаи, но rest-параметры всё ещё безопасный выбор.
• Выход за границы или дырявый доступ — провал CheckBounds или переход упакованного массива в дырявый elements kind.

Диагностируйте через --trace-deopt (каждый деопт с его функцией, смещением байт-кода и причиной) и, в d8 под --allow-natives-syntax, %GetOptimizationStatus(fn), чтобы прочитать биты яруса функции. Урок браузерного трека спекулятивный движок TurboFan и ловушка цикла деоптимизации проходит полную трассировку-и-починку; здесь упор на механизм и паттерн починки: отвести патологическое значение на отдельный медленный путь до горячего блока, чтобы быстрый путь оставался стабильным по типам.