Спекуляция и guards

Оптимизм под защитой

Предыдущие уроки задали входы: обратная связь говорит «этот сайт всегда видел карту M и Smi-операнды», и TurboFan может на этом специализироваться. Но «всегда видел» — утверждение о прошлом. JavaScript волен передать функции что-то иное при следующем вызове. Спекулятивная оптимизация разрешает это напряжение простым контрактом: предположи наблюдённые типы, выпусти код, валидный только под этим предположением, и защити каждое предположение guard, который дёшево проверяет его перед исполнением быстрого кода.

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

Guards, которые вы увидите в причинах --trace-deopt:

• CheckMaps — «у этого объекта всё ещё hidden class M». Охраняет загрузку/сохранение свойства по фиксированному смещению. Причина провала: wrong map.
• CheckSmi / CheckNumber — «это значение — малое целое» / «это число». Охраняет целочисленную или float64-арифметику без проверок тегов и боксинга. Причина провала: not a Smi, not a heap number.
• CheckBounds — «этот индекс в пределах длины массива». Охраняет сырую загрузку элемента без перепроверки границ внутри цикла. Причина провала: out of bounds.
• CheckString, CheckInternalizedString, CheckHeapObject и им подобные — аналогичные guards для строковых и указательных предположений.

Инлайнинг: сплавление guards и тел

Задайте себе вопрос: если оптимизатор не видит сквозь границу вызова, что происходит с guard, который вызывающий уже доказал, а вызываемый дублирует? Без инлайнинга вы платите за него дважды. Вызов функции — это барьер: оптимизатор не видит сквозь него, а сам вызов стоит настройки фрейма. Инлайнинг (встраивание вызываемого в граф вызывающего) убирает барьер для небольших горячих вызываемых, чья обратная связь называет известную цель. TurboFan вплетает граф вызываемого в вызывающего, и теперь guards вызываемого и вызывающего живут в одной области. Выигрыши накапливаются:

• CheckMaps, который вызывающий уже доказал, не повторяется внутри встроенного тела (устранение избыточности через границу инлайна).
• Чистое вычисление вызываемого можно планировать вместе с вызывающим, выносить из общих циклов, объединять как общие подвыражения.
• Escape-анализ (далее) теперь может увидеть, что объект, который вызываемый аллоцирует и возвращает, на самом деле никогда не покидает объединённую функцию.

Полиморфный инлайнинг обрабатывает до ~4 известных целей с предварительной проверкой карты, диспетчеризующей между встроенными телами; сверх этого сайт мегаморфный, и вызов остаётся обобщённым, не встроенным.

Escape-анализ: удаление аллокации

Это оптимизация, которая удивляет людей больше всего, ведь она делает объекты бесплатными. Escape-анализ спрашивает о каждой аллокации: покидает ли функцию хоть какая-то ссылка на этот объект — сохранена в поле, переживающее вызов, передана вызываемому, который мог бы её удержать, возвращена? Если ответ нет — объект чисто локальный блокнот, — TurboFan выполняет скалярную замену (scalar replacement): удаляет аллокацию целиком и заменяет поля объекта обычными SSA-значениями, живущими в регистрах.

Рассмотрим горячее вычисление расстояния, строящее временную точку:

function dist(ax, ay, bx, by) {
  const d = { x: ax - bx, y: ay - by }; // временный объект, не покидает функцию
  return Math.sqrt(d.x * d.x + d.y * d.y);
}

Без escape-анализа каждый вызов аллоцирует d в куче, пишет два поля, читает их обратно и оставляет мусор для GC. С escape-анализом TurboFan доказывает, что d никогда не покидает dist, удаляет аллокацию и трактует d.x и d.y как два значения в регистрах. Выпущенный код имеет нулевую аллокацию в куче, без записей полей, без чтений полей и не создаёт давления на GC — объект существовал только в исходном тексте, а не в работающем машинном коде. Это огромно для временных точек, итераторов, мешков опций и промежуточных при деструктуризации, которыми пронизан реальный код: написаны для ясности, скомпилированы в ничто.