Внутри цикла интерпретатора

Цикл диспетчеризации

Предыдущий урок оставил нас с байт-кодом функции и набором общих обработчиков (по одному на опкод, написанных на Torque). Исполнение — это акт запуска этих обработчиков по очереди. Концептуально:

loop:
  opcode  = bytecode[pc]        // выбрать текущий опкод
  handler = handlerTable[opcode] // найти его обработчик
  jump handler                   // сделать работу; обработчик продвигает pc, затем диспетчеризует следующий

Каждая итерация выбирает опкод по текущему указателю байт-кода (pc), ищет обработчик этого опкода в таблице и переходит к нему. Обработчик читает свои операнды (из регистрового файла и аккумулятора), выполняет операцию, пишет результат (обычно обратно в аккумулятор), продвигает pc за операнды этой инструкции, а затем диспетчеризует следующую инструкцию. Гоняйте этот цикл до Return — и вы исполнили функцию.

Как переход делается быстрым: threaded-диспетчеризация

Наивный интерпретатор написал бы это как гигантский switch (opcode) внутри while-цикла. Это работает, но у этого есть скрытая цена: после каждого обработчика поток управления возвращается к началу цикла и заново входит в switch, и предсказатель переходов CPU видит один-единственный косвенный переход, общий для всех опкодов — поэтому он предсказывает плохо и тормозит.

Вместо этого Ignition использует threaded-диспетчеризацию: каждый обработчик завершается, напрямую диспетчеризуя следующий обработчик — исторически через вычисляемый goto (один косвенный переход на обработчик), а в Ignition конкретно через tail call из машинного кода одного обработчика прямо в следующий. Выигрыш — для предсказания переходов: точка диспетчеризации каждого опкода — это её собственный косвенный переход, поэтому предсказатель может выучить частого преемника каждого опкода (например, за сравнением обычно идёт ветвление), вместо того чтобы путаться в одном общем переходе. Меньше промахов предсказания — более плотный, быстрый цикл интерпретатора.

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

Профилирование во время интерпретации: обратная связь заполняется

Цикл не просто исполняет — он учится. Вспомните, что каждый чувствительный к типам байт-код несёт слот feedback vector. По мере того как эти обработчики работают, они заполняют слоты map (hidden classes) и типами, которые реально наблюдают: этот LdaNamedProperty увидел объект с map M; этот Add увидел два Smi; этот Call всегда нацеливался на функцию F. К тому моменту, как функция поработала какое-то время, её feedback vector — компактный профиль того, как она реально используется — ровно та информация, что нужна оптимизатору. Интерпретатор готовит JIT как побочный эффект исполнения программы.

Interrupt budget: как цикл решает повысить ярус

Как V8 узнаёт, что функция достаточно горячая для компиляции? Он не считает буквально каждую инструкцию. Каждая функция несёт interrupt budget (бюджет прерываний — счётчик обратных рёбер и вызовов, по достижении нуля запускающий компиляцию). Цикл уменьшает этот бюджет на событиях, коррелирующих с нагревом:

• Обратные рёбра — каждый раз, когда управление прыгает назад к началу цикла (одна итерация for/while). Плотный цикл прожигает бюджет быстро.
• Вызовы функций / инвокации — повторный вход в функцию.

Когда бюджет достигает нуля, цикл поднимает запрос на повышение яруса: скомпилировать эту функцию следующим ярусом (Sparkplug, затем Maglev, затем TurboFan — юнит 04). Для цикла, который всё ещё работает, когда он становится горячим, V8 может даже подменить работающий код прямо посреди цикла через on-stack replacement (OSR) (замена на стеке — механизм подмены интерпретируемого фрейма на скомпилированный без остановки исполнения), перепрыгнув из интерпретатора в свежескомпилированный код, не дожидаясь окончания цикла. Обратные рёбра — ключевой сигнал: долго работающий цикл — каноничный триггер «это горячо, оптимизируй сейчас».

Почему интерпретация сначала — безопасный дефолт

Когда профилируешь функцию и видишь, что она тратит время в интерпретаторе, это не баг — это движок делает ровно то, что должен, пока у него недостаточно данных для спекуляций. Интерпретация медленнее на инструкцию, чем оптимизированный машинный код — на каждом байт-коде есть накладные расходы выборки-и-диспетчеризации. Но она предсказуема: нет паузы на компиляцию (байт-код готов сразу) и нет деопта — интерпретатор не делает спекулятивных предположений о типах, поэтому он не может ошибиться в типах и быть вынужден откатиться. Оптимизированный код быстрее, но может деоптимизироваться обратно в этот цикл, когда предположение ломается (деопт всегда приземляет вас обратно в интерпретатор). Так что Ignition — это и дешёвая стартовая точка, и страховочная сеть, в которую падает JIT. Поэтому каждая функция начинает свою жизнь прямо здесь, в цикле диспетчеризации, и поэтому этот урок стоит на шве между «как исполняется JS» и машинерией JIT юнита 04.