Области видимости, контексты и scope chain

Лексическая область: цепочка, заданная тем, где вы написали код

JavaScript использует лексическую область видимости: смысл идентификатора задаётся текстовой вложенностью функций и блоков, а не тем, кто кого вызвал во время работы. Когда вы ссылаетесь на total, язык задаёт поиск: смотрим в текущей области, затем в охватывающей, затем в следующей, вплоть до глобальной. Побеждает первое найденное объявление. Эта упорядоченная последовательность охватывающих областей и есть scope chain (цепочка областей видимости).

Слово «поиск» наносит большой вред в ментальной модели большинства людей. Линейный поиск именованных переменных во время работы — словарный lookup на каждый доступ — сделал бы каждое чтение переменной в замыкании мучительно медленным. В типичном случае V8 так не делает. Он разбивает работу на две половины: анализ на этапе компиляции, который вычисляет, где живёт каждая переменная, и рантайм-структуру, которая хранит лишь те переменные, которым действительно нужно пережить кадр.

ScopeInfo: чертёж этапа компиляции

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

• какие переменные объявляет область (имена),
• какие из них context-allocated — должны жить в куче, потому что их захватывает внутренняя функция — против stack/register-allocated (чисто локальные),
• индекс слота, который занимает каждая context-allocated переменная,
• вид области (function, block, eval, module, with) и ссылку на охватывающий ScopeInfo.

Главное: компилятор обычно может разрешить ссылку на переменную в фиксированную пару — (глубина контекста, индекс слота). «Переменная total находится на две области наружу, в слоте 3». Это разрешение запекается в байт-код инструкцией вида LdaContextSlot. Во время работы поиска по имени не происходит — это индексация массива в известный объект на известной глубине.

Context: scope chain во время работы

Во время работы области, которые должны пережить свой кадр стека, материализуются как объекты Context. Context — это небольшой кучевой объект (внутри — массив фиксированного размера, разновидность FixedArray), который хранит context-allocated переменные одной области плюс указатель на свой outer Context. Эта цепочка outer-указателей и есть scope chain во время работы.

Отсюда следуют три вещи, и они управляют всем в этом юните:

1. В Context попадают только захваченные переменные. Если компилятор может доказать, что переменная чисто локальна — объявлена, использована и ни одной внутренней функцией не упоминается — она остаётся в регистре CPU или на стеке и никогда не аллоцируется в куче. Она исчезает, когда кадр возвращается. Ни одно замыкание её не достанет, потому что ни одного над ней не создавалось.
2. Context индексируется по слоту, а не по имени. Чтение total на два уровня наружу — это: разыменовать outer, разыменовать outer ещё раз, загрузить слот 3. Фиксированная работа, без хеширования.
3. Глобальная область особая. Это глобальный объект (globalThis) плюс script context, который хранит top-level let/const. Top-level var и объявления функций становятся свойствами глобального объекта; top-level let/const живут в script context как cell’ы. Поэтому глобальные чтения идут через cell или загрузку свойства, а не через слот контекста, и кэшируются inline cache так же, как чтения свойств объектов.

Вместе правила 1 и 2 означают: кучевую цену платят только те переменные, которые внутренняя функция реально наблюдает — всё остальное бесплатно. Правило 3 объясняет, почему код модуля верхнего уровня имеет немного иную стоимость доступа, чем код внутри функции — это стоит знать, если вы переносите горячие чтения на уровень модуля в ожидании ускорения.

Почему быстрый путь существует — и что его разрушает

Вся оптимизация держится на том, что компилятор знает расположение статически. Две возможности языка ломают эту гарантию и загоняют V8 на медленный путь по именам:

• with (obj) внедряет объект, чьи свойства неизвестны до момента работы, поэтому любой идентификатор внутри может разрешиться в свойство obj. Компилятор не может предвычислить слот; он обязан выпустить динамический lookup, который сначала проверяет объект. Это отравляет область для оптимизации.
• Нестрогий eval может объявить новые переменные в вызывающей области (например, eval строки с var x = 1). Поскольку компилятор не может знать, какие имена внесёт eval, он обязан держать область динамической — переменные больше нельзя разрешить в фиксированные слоты, и охватывающую функцию часто нельзя хорошо оптимизировать.

Strict mode нейтрализует случай eval: eval в strict mode получает собственную область и не может протекать объявлениями наружу, поэтому окружающая область остаётся статически анализируемой. Это одна из конкретных причин по производительности, ради которых существует strict mode.

function fast(rows) {
  let total = 0;                 // захвачена стрелкой -> context-allocated
  rows.forEach(r => total += r); // 'total' разрешается в (глубина 1, слот 0)
  return total;
}

function slow(rows, cfg) {
  with (cfg) {                   // каждый идентификатор ниже теперь динамический
    let total = 0;               // V8 не может доказать, откуда берётся 'limit'
    rows.forEach(r => { if (total < limit) total += r; });
    return total;
  }
}