ブロックスコープの密室：forループ内 `let` がV8のヒープとGCに与える不可視の代償
JavaScriptの仕様書（ECMAScript Specification）をただ読み解くだけのプログラマと、V8エンジンのソースコードや Ignition / TurboFan のパイプラインを脳内でアセンブルできるエンジニアの間には、埋めがたい深い溝がある。
その溝の底にあるのが、「変数宣言の文法糖衣」という幻想だ。
私たちは日常的に `let` や `const` を使い、ブロックスコープの美しさに酔いしれている。だが、シニアエンジニアやランタイムアーキテクトであれば、モダンな構文の背後でV8ヒープがどのような物理的ストレスに晒されているかを知るべきだ。
特に、「forループのヘッドにおける `let` 宣言」は、単なるスコープの閉じ込めという綺麗事では済まされない。ループの反復ごとに生成されるレキシカル環境のクローン、Hidden Class（隠しクラス）の動的生成、そしてガベージコレクション（GC）のライフサイクルに対する影響は、高スループットを要求されるバックエンドや、60fpsを死守すべきフロントエンドにおいて、しばしば致命的なパフォーマンスのボトルネックとなる。
本稿では、V8エンジンのメモリレイアウトと実行モデルの深層に潜り、forループ内 `let` が引き起こすメモリ消費のメカニズムを、プロファイリングの視点から丸裸にする。
—
1. 伝統的 `var` と `let` のランタイム表現の決定的な違い
まずは、ランタイムが何を行っているのかをプリミティブなレベルで確認する。以下のコードを比較してほしい。
// パターンA: 関数スコープの var
function runVar() {
var i = 0;
for (i = 0; i < 3; i++) {
setTimeout(function() {
console.log(i);
}, 100);
}
}
// パターンB: ブロックスコープの let
function runLet() {
for (let i = 0; i < 3; i++) {
setTimeout(function() {
console.log(i);
}, 100);
}
}
パターンAの `var` では、変数 `i` は関数 `runVar` の Activation Object（Function Environment）上に単一の領域として確保される。ループが回るたびに `i` は上書きされ、非同期の `setTimeout` コールバックが実行される頃には、すべてのクロージャが同じ `i`（値は3）を参照する。
一方、パターンBの `let` はECMAScript仕様上、「各ループの反復（Iteration）ごとに、新しいレキシカル環境（Lexical Environment）を生成し、その中に新しいバインドを作成する」ことが義務付けられている。
V8エンジン（Ignitionインタープリタ）はこの仕様を厳密に実装するため、単にスタック上の変数を書き換えているわけではない。ループが1回回るごとに、ヒープ上に新たなレキシカル環境オブジェクト（Context）をアロケートしているのだ。
—
2. V8ヒープにおけるレキシカル環境のクローン生成とメモリレイアウト
V8のメモリ空間（Heap）において、スコープは「Context」と呼ばれる内部オブジェクトとして表現される。関数スコープであれ、ブロックスコープであれ、外部から参照される（あるいはクロージャによってキャプチャされる）可能性のある変数は、この Context オブジェクトの中にスロットとして格納される。
forループのヘッドで `let i` が宣言された場合、V8は以下のステップを踏む：
1. ループ開始前の初期化: ループ全体のスコープを表す Outer Context が生成される。
2. 反復ごとのループ内 Context のインスタンス化: 各イテレーション（$i = 0$, $i = 1$, $i = 2$）に入るたびに、前回のループの Context とは別に、新しい Context がヒープ上にアロケート（クローン生成）される。
3. 変数のシャドウイングと初期化: 前のイテレーションの `i` の値を評価しつつ、新しい Context 内の `i` に値をバインドする。
もしループ内でクロージャ（今回の例では `setTimeout` のコールバック）が定義され、その変数をキャプチャしている場合、V8のガベージコレクタ（Orinoco）は厄介な問題に直面する。
クロージャが生き残っている限り、各イテレーションごとに生成された個別の Context オブジェクトを解放することができない。結果として、ヒープ上には寿命の異なる複数の Context オブジェクトが散らばり、マイナーGC（Scavenger）の生存領域（To-space / From-space）の間で不要なオブジェクトのコピー（昇格）が発生し、メモリフラグメンテーションやGC一時停止（Stop-the-world）の要因となる。
—
3. プロファイラによるメモリ追跡：何がアロケートされているのか？
この現象をNode.jsの `–inspect` および V8ヒーププロファイラを用いて実証する。以下のスクリプトを実行し、ヒープスナップショットを解析せよ。
// heap-analysis.js
‘use strict’;
const v8 = require(‘v8’);
function allocateContextsWithLet() {
let handlers = [];
// 大量のループとクロージャの生成
for (let i = 0; i < 100000; i++) {
handlers.push(function() {
return i;
});
}
return handlers;
}
// 実行前のヒープ統計
console.log('Before GC Heap Used:', process.memoryUsage().heapUsed);
global.gc && global.gc();
const handlers = allocateContextsWithLet();
// 実行後のヒープ統計
console.log('After Allocation Heap Used:', process.memoryUsage().heapUsed);
// V8のヒープ統計詳細を取得
const heapStats = v8.getHeapStatistics();
console.log(`Heap Size Limit: ${heapStats.heap_size_limit / 1024 / 1024} MB`);
console.log(`Total Allocated Heap: ${heapStats.total_heap_size / 1024 / 1024} MB`);
このコードを `--expose-gc` フラグをつけて実行すると、`let` を使ったループとクロージャの組み合わせがいかに多くの Context オブジェクトをヒープ上に生成し、メモリフットプリントを肥大化させるかが数値として現れる。
node --expose-gc heap-analysis.js
ブラウザのChrome DevToolsやNode.jsのHeap Snapshotでこれを解析すると、`Context` というコンストラクタを持つオブジェクトが大量に存在し、それぞれが独立したスコープ変数（この場合は `i`）を保持していることが確認できる。もしこれが数百万回のループ、あるいはリアルタイム性の高いWebアプリケーションのレンダリングループ内であれば、GCのプレッシャーは計り知れない。
---
4. 高度な最適化：V8はどのようにこのオーバーヘッドを回避するか？
ここで一つ疑問が湧く。現代のV8エンジン（TurboFanコンパイラ）は非常に優秀である。もしクロージャによって変数がキャプチャされていない場合、V8は本当に毎イテレーションごとにContextをアロケートし続けているのだろうか？
答えは「否」だ。
V8の Ignition / TurboFan パイプラインには、Escape Analysis（エスケープ解析） と呼ばれる強力な最適化パスが存在する。
もしループ内で定義された関数やオブジェクトがスコープの外に「逃げない（escapeしない）」とコンパイラが静的解析で判断した場合、V8はヒープ上への Context のアロケートを完全にバイパスする。代わりに、レジスタ上またはスタック上の単なる一時変数、あるいは単純なループ変数としてインライン展開する。
しかし、以下の条件のいずれかに当てはまった瞬間、エスケープ解析は失敗し、コストの高いヒープアロケーションが強制される。
- ループ内で定義された関数（アロー関数含む）が、スコープ外の変数や配列に格納される（今回の `setTimeout` や `handlers.push` の例）。
- `eval()` や `with` ステートメントがスコープ内に存在する（これらは静的解析を完全に無力化する）。
- デバッグセッションがアタッチされており、ランタイムが変数のライフタイムを正確に追跡する必要がある。
つまり、「モダンなJavaScriptだから安全」と過信して複雑なクロージャをループ内で量産すると、エスケープ解析の網をすり抜け、V8のヒープアロケータを直撃することになる。
—
5. 極限環境における防御とアーキテクチャの選択
では、パフォーマンスが極限まで求められるコードベース（例：高頻度トレーディングシステム、ゲームエンジン、コアライブラリ）において、我々はこのオーバーヘッドをどう回避すべきか。
対策1: ループ変数のスコープを外側に引き出す（Manual Hoisting）
クロージャをループ内で生成せざるを得ない場合、必要に応じてレキシカル環境の生成を明示的に制御する。
// 改善版: レキシカル環境の乱造を防ぐため、必要なスコープを手動で分離
function optimizedRun() {
let handlers = [];
// ループ外で単一のコンテキスト、または明示的なファクトリ関数を使用
for (var i = 0; i < 100000; i++) {
// 即時実行関数 (IIFE) やファクトリ関数でスコープを明示的に切り、
// 必要な値だけをクロージャに閉じ込める
handlers.push(createHandler(i));
}
return handlers;
}
function createHandler(val) {
// 値を引数として渡すことで、参照ではなく値のコピーとしてキャプチャさせる
return function() {
return val;
};
}
対策2: イミュータブルなデータ構造と配列の事前アロケーション
無駄なオブジェクト生成を避けるため、ループ内で動的に配列やオブジェクトを拡張するのではなく、`TypedArray` や事前にサイズを確定させたコンテナを使用する。これにより、V8のガベージコレクタの世代別回収（Generational GC）における Old Space への昇格を最小限に抑えることができる。
—
結言：ランタイムと対話するコードを書け
JavaScriptは「動的で簡単な言語」という神話は、シニアエンジニアの机の上で廃棄されるべきだ。ブラウザのレンダリングパイプラインを動かし、V8のヒープメモリ空間を脈打たせているのは、他ならぬ私たちが書いたコードの1行1行である。
`let` がもたらすブロックスコープの安全性は素晴らしい。しかし、その糖衣構文の背後で、V8エンジンがどれほどのコストを払ってレキシカル環境のクローンを管理しているか。その物理的なメカニズムを理解した者だけが、真にスケーラブルで予測可能なパフォーマンスを持つアプリケーションを構築できる。
ランタイムを欺くな。ランタイムと対話せよ。