On-Stack Replacement: подмена фрейма посреди цикла

Проблема, которую обычное повышение яруса не решает

Вспомните, как повышение яруса устанавливает оптимизированный код (урок 01): когда бюджет функции срабатывает, V8 компилирует более быструю версию и подменяет её для следующего входа в функцию. У этой модели есть слепое пятно. Рассмотрим функцию, которая вызывается однажды и проводит всё своё время в одном длинном цикле:

function crunch(rows) {
  let acc = 0;
  for (let i = 0; i < rows.length; i++) {   // 10 000 000 итераций
    acc += score(rows[i]);
  }
  return acc;
}
crunch(tenMillionRows); // вызвана ровно один раз

Цикл ослепительно горячий — миллионы обратных дуг — так что его счётчик обратных дуг срабатывает по бюджету почти немедленно (урок 01 ввёл этот счётчик ровно для этого случая). V8 хочет оптимизировать. Но обычный механизм здесь бесполезен: он установил бы оптимизированный код для следующего вызова crunch, а crunch на лету посреди единственного вызова, который она когда-либо получит. К моменту возврата crunch работа уже сделана. Ждать повторного входа значит никогда не оптимизировать тот единственный цикл, что важен.

OSR: замена фрейма на лету

On-Stack Replacement — это механизм, разрывающий этот тупик. Вместо ожидания, пока функция вернётся и будет вызвана снова, V8 заменяет исполняющийся фрейм на месте, посреди цикла. Последовательность:

1. Счётчик обратных дуг цикла срабатывает по бюджету повышения яруса, пока цикл работает в интерпретаторе (или базовом ярусе).
2. V8 компилирует специальную OSR-entry-версию функции — оптимизированный машинный код, чья точка входа не вершина функции, а заголовок цикла. Она специализирована так, чтобы начать исполнение, как будто управление только что пришло к началу итерации цикла, со всеми живыми переменными цикла уже на месте.
3. V8 выполняет перенос живого состояния (live-state transfer): он читает текущие значения каждой живой переменной из интерпретаторного фрейма (индекс цикла i, аккумулятор acc, ссылка rows) и пишет их в регистры и слоты стека оптимизированного фрейма в тех представлениях, которые ожидает оптимизированный код. Это инверсия трансляции фрейма при деопте из урока 05 — там мы перестраивали интерпретаторный фрейм из оптимизированного; здесь мы строим оптимизированный фрейм из интерпретаторного.
4. Управление переходит в OSR-entry-оптимизированный код на заголовке цикла, и тот же цикл продолжается — но теперь в оптимизированном машинном коде. Оставшиеся девять с половиной миллионов итераций работают быстро.
5. После того как цикл закончен и crunch в итоге возвращается, обычный оптимизированный код (обычная компиляция со входом сверху) берёт на себя любые последующие вызовы.

Почему микробенчмарки живут и умирают по OSR

Это механизм за печально известной ловушкой бенчмаркинга. Если ваш бенчмарк запускается один раз и крутит один гигантский цикл, спросите себя: была ли ваша функция когда-либо вызвана достаточно раз, чтобы получить обычное повышение яруса? Ответ почти наверняка нет — вы целиком зависите от OSR. Микробенчмарк, оборачивающий свою работу в один огромный цикл — for (let i = 0; i < 1e9; i++) work(), — не разогревает work через повышение яруса по счётчику вызовов обычным образом; он полагается на то, что OSR включится на полпути, чтобы оптимизировать тело цикла на лету. Из этого следуют два последствия для всякого, кто замеряет производительность:

• Первый кусок итераций работает неоптимизированным (интерпретатор/базовый ярус), затем есть разрыв, где срабатывает OSR, и остаток работает быстро. Если вы замеряете весь цикл одним числом, вы смешиваете холодное и горячее исполнение и получаете бессмысленное среднее.
• OSR-entry-код может быть немного хуже обычной оптимизации со входом сверху, ведь он вынужден принять живое состояние цикла таким, каким нашёл, а не от чистого входа в функцию, что ограничивает некоторые оптимизации. Так что замер, разогретый через OSR, может занижать установившуюся скорость, которую вы увидели бы, если бы функцию вызывали много раз обычным образом.

Починка стандартная: разогрейте функцию многими отдельными вызовами до замера (чтобы она получила обычную, не-OSR оптимизацию), и замеряйте установившиеся итерации, а не разогревочный переходный процесс. Вы можете увидеть OSR через --trace-osr; вместе с --trace-opt он показывает OSR-entry-компиляцию отдельно от обычной.