Node.js Internals

V8: JavaScript движок

Почему один и тот же JavaScript-код может работать в 10-100 раз быстрее или медленнее? Секрет в V8 - движке, который **не интерпретирует код**, а компилирует его в нативные инструкции CPU. Но V8 - это не magic: он делает агрессивные предположения о коде (типы, структуры объектов). Нарушение этих предположений рушит производительность. Эта тема - о том, как V8 работает под капотом и как писать код, который V8 **любит**.

  • **Google Sheets (миллионы ячеек):** V8 оптимизирует горячие функции (пересчёт формул) через TurboFan, превращая их в машинный код. Если типы данных в ячейках стабильны (все числа), пересчёт работает на скорости C++. Если типы смешанные (числа + строки), происходят bailout'ы → формулы тормозят.
  • **Discord (real-time chat):** Node.js бекенд обрабатывает миллионы сообщений в секунду. Hidden Classes критичны: все объекты сообщений имеют одинаковую структуру (`{ id, userId, content, timestamp }`). Это позволяет V8 использовать inline caching - доступ к свойствам в 10x быстрее. Если структура меняется (добавляются динамические поля), IC ломается → throughput падает.
  • **Netflix (серверный рендеринг):** Node.js рендерит HTML на сервере. GC критически важен: если heap растёт бесконтрольно, Major GC паузы (50-100 мс) убивают latency. Netflix использует object pooling (переиспользование объектов) и настройку `--max-old-space-size` для минимизации GC-пауз. Результат: стабильный 99th percentile latency <10 мс.

V8 Architecture

V8 - это не просто интерпретатор JavaScript. Это высокооптимизированная машина, которая **компилирует** JS в нативный машинный код прямо во время выполнения. Написанный на C++, V8 используется в Chrome, Node.js, Deno и Electron. Его задача: сделать динамический язык настолько быстрым, что разница с C++ становится незаметной для многих задач.

**Почему V8 особенный?** До V8 (до 2008 года) JavaScript был медленным. Браузеры просто интерпретировали код построчно. Google создал V8 для Chrome с одной целью: сделать веб-приложения (Gmail, Google Maps) такими же быстрыми, как десктопные. V8 был первым движком, который применил **JIT-компиляцию** (Just-In-Time) для JavaScript, превращая код в нативные инструкции процессора.

**Ключевое отличие:** V8 не интерпретирует код. Он компилирует JavaScript в машинный код x64/ARM64, который CPU выполняет напрямую. Это делает V8 на порядки быстрее традиционных интерпретаторов.

**Компоненты V8:** **Parser** - превращает JavaScript-код в **AST** (Abstract Syntax Tree). V8 использует ленивый парсинг (lazy parsing): функции, которые не вызываются сразу, парсятся в упрощённом режиме (pre-parsing) для экономии времени. **Ignition** (интерпретатор байткода) - компилирует AST в **байткод** и выполняет его. Байткод - это компактное промежуточное представление (не машинный код, но уже не JS). Ignition быстро стартует код, собирая при этом статистику: какие функции вызываются часто (hot functions). **TurboFan** (оптимизирующий компилятор) - берёт горячие функции и компилирует их в **высокооптимизированный машинный код**. TurboFan применяет агрессивные оптимизации: inline caching, dead code elimination, escape analysis. Но если предположения не оправдываются (например, функция вдруг получила объект другого типа), TurboFan делает **деоптимизацию** (bailout) - откатывается к байткоду. **Orinoco GC** (Garbage Collector) - параллельный и инкрементальный сборщик мусора. Работает в фоновых потоках, минимизируя паузы (stop-the-world).

Почему V8 быстрее интерпретаторов

```javascript // Простая функция сложения function add(a, b) { return a + b; } // Вызываем миллион раз for (let i = 0; i < 1_000_000; i++) { add(i, i + 1); } ``` **Старый интерпретатор:** каждый раз парсит `a + b`, проверяет типы, вызывает операцию сложения. **V8 (TurboFan):** после ~100 вызовов видит, что `a` и `b` всегда числа → компилирует в машинный код: ```asm ; x64 assembly (упрощённо) mov rax, [rbp-8] ; загрузить a add rax, [rbp-16] ; добавить b ret ; вернуть результат ``` Результат: **100x+ ускорение** для горячих функций.

**Почему два компилятора (Ignition + TurboFan)?** Trade-off между скоростью запуска и скоростью выполнения. Ignition даёт быстрый старт, TurboFan - максимальную производительность для долгоживущего кода. Раньше V8 использовал Full-codegen (базовый компилятор) + Crankshaft (оптимизатор), но в 2017 перешёл на Ignition + TurboFan - это сэкономило память и упростило архитектуру.

**История V8:** Запущен в 2008 году вместе с Chrome. Создан командой Lars Bak (ранее работал над виртуальными машинами в Sun Microsystems). В 2009 Ryan Dahl взял V8 за основу Node.js. С тех пор V8 обновляется каждые 6 недель синхронно с релизами Chrome. Каждый релиз Node.js (например, Node 20) использует определённую версию V8.

**V8 vs JavaScriptCore vs SpiderMonkey:** V8 (Chrome/Node.js), JavaScriptCore (Safari), SpiderMonkey (Firefox) используют разные подходы к JIT-компиляции. Код, оптимизированный для V8, может работать медленнее в других движках. Например, V8 агрессивно оптимизирует hidden classes (об этом дальше), а SpiderMonkey использует другие техники (Inline Caching на основе типов). Но общие принципы (избегать смены типов, использовать стабильные структуры объектов) работают везде.

Какова основная роль Ignition в V8 pipeline?

JIT Compilation

**JIT (Just-In-Time) компиляция** - это сердце производительности V8. Вместо того чтобы выполнять JavaScript построчно (как интерпретатор) или компилировать весь код заранее (как AOT в C++), V8 делает и то, и другое: **компилирует код во время выполнения**, адаптируясь к реальному использованию.

**Как работает JIT-pipeline:** 1. **Быстрый старт (Ignition):** Код компилируется в байткод и сразу начинает выполняться. Это быстрее, чем генерация оптимизированного машинного кода. 2. **Профилирование:** Во время выполнения байткода V8 собирает статистику - **типы аргументов**, частоту вызовов, ветвления условий (какой `if`/`else` выполняется чаще). 3. **Оптимизация (TurboFan):** Когда функция становится **горячей** (hot), TurboFan компилирует её в нативный код с агрессивными оптимизациями. Например, если функция всегда получает числа, TurboFan генерирует код только для чисел (без проверок типов). 4. **Деоптимизация (Bailout):** Если предположения TurboFan оказываются неверными (например, функция вдруг получила строку вместо числа), происходит **bailout** - V8 откатывается к байткоду Ignition.

**Inline Caching (IC)** - ключевая техника JIT. V8 кеширует результаты операций (например, доступ к свойству объекта). При обращении `obj.x` V8 запоминает: "объект типа Shape1, смещение свойства x = 8 байт". Следующий доступ к `obj.x` - прямой read из памяти (offset +8), без поиска по имени. Но если `obj` меняет структуру (добавили свойство), IC инвалидируется.

Деоптимизация убивает производительность

```javascript function processUser(user) { return user.name + " " + user.age; } // Вариант 1: Стабильные типы (FAST) const users1 = [ { name: "Alice", age: 25 }, { name: "Bob", age: 30 }, { name: "Charlie", age: 35 } ]; for (const user of users1) { processUser(user); // TurboFan оптимизирует } // Вариант 2: Меняющиеся типы (SLOW) const users2 = [ { name: "Alice", age: 25 }, { name: "Bob", age: "30" }, // age теперь строка! { name: "Charlie", age: 35 } ]; for (const user of users2) { processUser(user); // Bailout каждый раз! } ``` **Benchmark:** Вариант 1 в ~5x быстрее. TurboFan генерирует оптимизированный код для чисел, но вариант 2 постоянно триггерит деоптимизацию.

**Как проверить, оптимизирована ли функция?** Запуск Node.js с флагами: ```bash node --trace-opt --trace-deopt script.js ``` В логах: - `[optimizing 0x... <multiply> ... ]` - функция оптимизирована TurboFan - `[bailout ... reason: ...] ` - деоптимизация (например, `Insufficient type feedback`)

**Почему деоптимизация так дорогая?** Когда происходит bailout, V8 должен: 1. Остановить выполнение оптимизированного кода 2. Восстановить состояние (stackframe) для байткода 3. Продолжить выполнение в Ignition 4. Заново профилировать функцию (если типы стабилизируются, TurboFan попробует оптимизировать снова) Это может занять **микросекунды** - не критично для одного вызова, но если функция вызывается миллионы раз, это превращается в секунды.

**Мегаморфные функции (megamorphic)** - это худший случай. Когда функция получает >4 разных типов аргументов, V8 помечает её как megamorphic и перестаёт оптимизировать. Inline caching (IC) тоже отключается. Решение: использовать **мономорфные** функции (один тип) или **полиморфные** (2-4 типа). Избегать ситуаций, где функция обрабатывает и числа, и строки, и объекты.

Hidden Classes

JavaScript - это динамический язык. Свойства объектам можно добавлять в любой момент: ```javascript const obj = {}; obj.x = 1; obj.y = 2; obj.z = 3; ``` В C++ структура объекта фиксирована на этапе компиляции, и компилятор знает: "свойство `x` находится на смещении +0 байт, `y` на +4 байта". Как V8 делает то же самое для JavaScript? Ответ: **Hidden Classes** (или Shapes, Maps).

**Hidden Class** - это внутреннее представление V8 для структуры объекта. Это как схема (blueprint), которая описывает: - Какие свойства есть у объекта - В каком порядке они добавлены - Где каждое свойство находится в памяти (offset) Когда создаётся объект `{ x: 1, y: 2 }`, V8 создаёт Hidden Class: "объект с двумя свойствами: x на offset 0, y на offset 8". При создании другого объекта `{ x: 10, y: 20 }` V8 переиспользует ту же Hidden Class - они имеют одинаковую структуру.

**Почему это важно?** Inline Caching (IC) работает только с объектами одного Hidden Class. Когда V8 видит `obj.x`, он кеширует: "это объект Shape1, свойство x на offset 0". Следующий доступ к `obj.x` - прямой read из памяти (одна asm-инструкция). Но если Hidden Class меняется, IC инвалидируется - V8 снова делает медленный lookup по имени свойства.

Оптимизация через Hidden Classes

```javascript // ПЛОХО: Разный порядок свойств const user1 = { name: "Alice", age: 25 }; // HiddenClass A const user2 = { age: 30, name: "Bob" }; // HiddenClass B (другой порядок!) // V8 создаёт ДВА разных Hidden Class - inline caching не работает // ХОРОШО: Одинаковый порядок const user1 = { name: "Alice", age: 25 }; // HiddenClass C const user2 = { name: "Bob", age: 30 }; // HiddenClass C (переиспользуется!) // V8 переиспользует Hidden Class - IC работает идеально ``` **Benchmark:** Второй вариант в ~2-3x быстрее для доступа к свойствам (особенно в циклах).

**Совет по производительности:** инициализировать все свойства объекта **в конструкторе** и в одном порядке. Не добавлять свойства динамически после создания объекта - это создаёт новые Hidden Classes и ломает IC. ```javascript // ХОРОШО class User { constructor(name, age) { this.name = name; this.age = age; } } // ПЛОХО class User { constructor(name) { this.name = name; } setAge(age) { this.age = age; // Добавляем свойство позже → новый Hidden Class } } ```

**Что убивает оптимизацию Hidden Classes:** 1. **`delete obj.property`** - удаление свойства переводит объект в slow mode (dictionary mode). V8 переключается с быстрого offset-based доступа на медленный hash-table lookup. **Никогда не использовать `delete` в hot path!** Вместо этого присваивать `null` или `undefined`. 2. **Добавление свойств в разном порядке** - создаёт разные Hidden Classes, ломает IC. 3. **Числовые индексы вперемешку с именованными свойствами**: ```javascript const obj = { x: 1 }; obj[0] = "value"; // V8 создаёт elements backing store (отдельная структура) obj.y = 2; // Именованные свойства в другой структуре ``` V8 разделяет объекты на две части: **elements** (числовые индексы) и **properties** (именованные свойства). Смешивать их - неэффективно.

Garbage Collection Basics

JavaScript - язык с автоматическим управлением памятью. Память освобождается не вручную (как в C/C++), а через **Garbage Collector (GC)**. В V8 используется **Orinoco** - параллельный, инкрементальный и генерационный сборщик мусора. Его задача: находить объекты, которые больше не используются, и освобождать память, минимизируя паузы (stop-the-world).

**Generational Hypothesis** - основа современных GC. Наблюдение: большинство объектов умирают молодыми (живут миллисекунды). Небольшая часть объектов живёт долго (минуты, часы). Поэтому V8 делит heap на **две генерации**: - **Young Generation (новые объекты):** Маленький размер (~8-16 MB). Объекты создаются здесь. GC запускается часто (каждые несколько миллисекунд), но работает быстро (1-5 мс). - **Old Generation (старые объекты):** Большой размер (сотни MB / несколько GB). Объекты, пережившие несколько GC-циклов, перемещаются сюда. GC запускается редко, но работает дольше (10-100 мс).

**Почему две генерации?** Сканировать весь heap каждый раз - дорого. Young Generation маленькая → GC проходит быстро. Old Generation сканируется редко, когда накопится много мусора. Это trade-off: частые быстрые паузы (Young GC) vs редкие длинные паузы (Old GC).

**Scavenge (Young Generation GC):** Молодые объекты размещаются в **From-Space**. Когда From-Space заполняется, V8 запускает **Scavenge** (алгоритм Cheney's copying): 1. **Найти живые объекты:** GC сканирует корни (stack, глобальные переменные) и помечает объекты, на которые есть ссылки. 2. **Эвакуация:** Живые объекты копируются в **To-Space**. Мёртвые объекты просто игнорируются (автоматически освобождаются). 3. **Swap:** From-Space и To-Space меняются местами. Скорость Scavenge: **1-5 мс**. Это почти незаметно. Если объект пережил **2 Scavenge-цикла**, он считается долгоживущим и перемещается в **Old Generation** (tenure/promotion).

**Mark-Sweep-Compact (Old Generation GC):** Когда Old Generation заполняется, V8 запускает **Major GC** (полный цикл): 1. **Marking (маркировка):** GC сканирует весь heap, помечая живые объекты (начиная с корней, обходя граф объектов). Это **инкрементальный процесс** - выполняется маленькими шагами между выполнением JS-кода. 2. **Sweeping (подметание):** GC проходит по памяти, освобождая места, где нет меток (мёртвые объекты). 3. **Compacting (уплотнение):** GC перемещает живые объекты ближе друг к другу, убирая фрагментацию памяти. Это позволяет выделять новые объекты быстрее (bump allocation). Скорость Major GC: **10-100 мс** (зависит от размера heap). Это может вызвать заметные паузы (lag в UI, задержки в API).

Как видеть GC-паузы

Node.js с флагом `--trace-gc`: ```bash node --trace-gc app.js ``` Вывод: ``` [12345:0x...] Scavenge 2.3 (3.1) -> 1.8 (4.1) MB, 1.2 / 0.0 ms ... [12345:0x...] Mark-sweep 45.2 (52.0) -> 38.1 (50.0) MB, 23.4 ms ... ``` - **Scavenge:** 1.2 мс (быстро) - **Mark-sweep:** 23.4 мс (заметная пауза!) Частые Major GC (>10 раз в секунду) означают либо утечку памяти, либо слишком маленький heap.

Ключевые идеи

  • **V8 использует JIT-компиляцию:** Ignition (быстрый старт → байткод) + TurboFan (оптимизация горячих функций → машинный код). Стабильные типы → 100x ускорение. Смешанные типы → bailout → деградация до интерпретации.
  • **Hidden Classes оптимизируют доступ к свойствам:** V8 создаёт внутреннюю схему структуры объекта. Объекты с одинаковой структурой переиспользуют Hidden Class → inline caching работает (O(1) доступ). Разные порядки свойств, `delete`, числовые индексы → разные Hidden Classes → IC ломается.
  • **Garbage Collector (Orinoco) использует generational подход:** Young Generation (частые быстрые GC) + Old Generation (редкие долгие GC). Меньше временных объектов (через pooling) и без утечек (глобальные переменные, забытые обработчики событий).
  • **Оптимизация V8 требует предсказуемости:** Стабильные типы, стабильные структуры объектов, избегание `delete`/`eval`/`arguments`. V8 награждает дисциплинированный код производительностью C++, но наказывает динамизм деоптимизациями.

Связанные темы

V8 - это фундамент производительности Node.js. Понимание его работы критично для следующих тем:

  • Event Loop & Async I/O — Event Loop работает в одном потоке с V8. GC-паузы блокируют event loop → задержки в обработке запросов. Оптимизация GC напрямую влияет на latency.
  • Memory Management — Heap limits, buffer allocation, Worker Threads для изоляции heap - всё строится на понимании GC и V8 memory model.
  • Performance Profiling — Flame graphs, CPU profiling, heap snapshots - инструменты для анализа V8 оптимизаций и поиска bottlenecks.

Вопросы для размышления

  • Почему функция, которая обрабатывает и числа, и строки, работает медленнее, чем две отдельные функции (одна для чисел, другая для строк)?
  • В каких сценариях использование `delete obj.property` может быть оправдано, несмотря на переход в dictionary mode? (Подсказка: когда производительность не критична, но нужна семантическая корректность.)
  • Как object pooling помогает избежать GC-пауз? Какой trade-off возникает при использовании pooling? (Подсказка: сложность кода vs производительность.)

Связанные уроки

  • comp-32-jvm
V8: JavaScript движок

0

1

Войти

**Оптимизации TurboFan:** - **Inlining** - встраивание маленьких функций прямо в caller (убирает overhead вызова) - **Escape Analysis** - если объект не покидает функцию, V8 размещает его на стеке вместо кучи (heap) - **Dead Code Elimination** - удаление неиспользуемого кода - **Loop Unrolling** - развёртывание циклов - **Type Specialization** - генерация кода под конкретные типы (числа, строки) Все эти оптимизации работают **только если типы предсказуемы**.

Что произойдёт, если функция, оптимизированная TurboFan, неожиданно получит аргумент другого типа?

**Dictionary Mode (slow properties):** если объект имеет слишком много свойств (>100-1000) или используется `delete`, V8 переключает объект в dictionary mode. Вместо Hidden Class с фиксированными offsets, свойства хранятся в hash-table. Доступ замедляется в ~10x. Это необратимо - объект навсегда остаётся в slow mode. Проверка режима: ```bash node --allow-natives-syntax script.js ``` ```javascript const obj = { x: 1 }; delete obj.x; console.log(%HasFastProperties(obj)); // false (dictionary mode) ```

**Hidden Classes и классы ES6:** ```javascript class Point { constructor(x, y) { this.x = x; this.y = y; } } const p1 = new Point(1 2); const p2 = new Point(3 4); ``` Оба объекта `p1` и `p2` имеют одинаковый Hidden Class (создан на основе класса `Point`). V8 очень эффективно работает с ES6 классами - это **лучший способ** создавать множество объектов одинаковой структуры.

Почему использование `delete obj.property` критически замедляет доступ к свойствам объекта в V8?

**Оптимизация GC: Object Pooling** При создании миллионов временных объектов (например, в игровом цикле или парсере) GC будет срабатывать очень часто. Решение: **Object Pooling** - переиспользование объектов вместо создания новых. ```javascript // ПЛОХО: Создаём миллион объектов for (let i = 0; i < 1_000_000; i++) { const point = { x: i, y: i }; // GC будет страдать process(point); } // ХОРОШО: Переиспользуем объект const point = { x: 0, y: 0 }; for (let i = 0; i < 1_000_000; i++) { point.x = i; point.y = i; process(point); } ``` Второй вариант: **нулевые** GC-паузы (объект не умирает → не нужен Scavenge).

**Memory Leaks в JavaScript:** Несмотря на GC, утечки памяти возможны. Типичные причины: 1. **Глобальные переменные:** ```javascript function leak() { data = new Array(1_000_000); // Забыли let/const → глобальная переменная } leak(); // data живёт вечно ``` 2. **Забытые обработчики событий:** ```javascript const button = document.getElementById("btn"); button.addEventListener("click", () => { // Обработчик держит ссылку на весь scope }); // Если кнопка удаляется из DOM, но обработчик не отписан → утечка ``` 3. **Замыкания (closures):** ```javascript function createHandler() { const bigData = new Array(1_000_000); return () => { console.log(bigData[0]); // Замыкание держит ссылку на bigData }; } const handler = createHandler(); // bigData не может быть собран GC ``` Решение: использовать WeakMap/WeakSet для объектов, которые должны автоматически удаляться.

**Incremental и Concurrent GC:** Orinoco (современный GC в V8) использует **инкрементальную маркировку** (incremental marking) и **параллельное подметание** (concurrent sweeping): - **Incremental:** Маркировка разбивается на маленькие шаги (~5-10 мс). Между шагами выполняется JavaScript-код. Это делает паузы менее заметными. - **Concurrent:** Sweeping и Compacting выполняются в **фоновых потоках** (background threads), пока основной поток выполняет JS. Это радикально сокращает stop-the-world паузы. Результат: Major GC в V8 может занимать всего **5-10 мс** (вместо 100 мс в старых версиях).

**Мониторинг памяти в Node.js:** ```javascript const memUsage = process.memoryUsage(); console.log({ rss: memUsage.rss / 1024 / 1024, // Resident Set Size (total memory) heapTotal: memUsage.heapTotal / 1024 / 1024, // Allocated heap heapUsed: memUsage.heapUsed / 1024 / 1024, // Used heap external: memUsage.external / 1024 / 1024, // C++ objects (buffers) }); ``` Если `heapUsed` постоянно растёт и не падает после GC - это утечка памяти. Для анализа применяется Chrome DevTools (Memory Profiler) или `node --inspect`.

Garbage Collector всегда работает в фоновом потоке и никогда не останавливает выполнение JavaScript-кода

GC иногда требует stop-the-world паузы, хотя V8 минимизирует их через incremental и concurrent алгоритмы

Даже современный Orinoco GC делает короткие stop-the-world паузы (1-10 мс) для критических операций (например, сканирование stack, финализация маркировки). Incremental marking разбивает работу на шаги, а concurrent sweeping/compacting работают в фоне, но **полностью избежать пауз невозможно** - V8 должен гарантировать консистентность heap. В Node.js приложениях с большим heap (>1 GB) Major GC может вызвать паузы 20-50 мс, что критично для low-latency сервисов (например, real-time API). Решение: настройка `--max-old-space-size`, использование Worker Threads для изоляции heap, избегание утечек памяти.

Что произойдёт, если объект в Young Generation переживёт 2 Scavenge-цикла?