V8エンジンの深淵：forループにおける `let` のレキシカル環境クローンとGCのライフサイクル
JavaScriptのランタイム、特にGoogle ChromeやNode.jsの心臓部であるV8エンジンにおいて、変数の宣言方法ひとつがメモリ空間に与える影響は、表面的な仕様書が語るよりも遥かに複雑かつ魅力的だ。
多くのジュニア、あるいはミドルクラスのエンジニアは「`let` や `const` はブロックスコープを持ち、`var` のような巻き上げによる意図しない変数の共有を防ぐ」という教科書通りの理解で満足している。しかし、シニアアーキテクトやV8の内部挙動に精通したエンジニアであれば、ループイテレーションごと、すなわち `{}` のブロック境界を跨ぐたびにV8が何を行っているかを知らなければならない。
今回は、ES2015（ES6）で導入された `let` が `for` ループのイテレーションごとに生成する「レキシカル環境（Lexical Environment）のクローン」と、それがV8のヒープメモリ、ガベージコレクション（GC）、そしてクロージャの生存期間にどう影響を与えるのかを、ランタイムの低レイヤ視点から完全に解剖する。
—
1. 伝統的悪夢：`var` と関数スコープの残骸
まず、比較対象として `var` がV8のヒープ上でどのように扱われていたかを振り返る。
// 【アンチパターン】varによるスコープ汚染とクロージャの罠
function createAsyncTasksVar() {
var tasks = [];
for (var i = 0; i < 3; i++) {
tasks.push(function() {
console.log(`Task var: ${i}`);
});
}
return tasks;
}
const funcsVar = createAsyncTasksVar();
funcsVar.forEach(fn => fn());
// 出力結果:
// Task var: 3
// Task var: 3
// Task var: 3
なぜこうなるのか？ V8のコンパイラ（Ignition）の視点から見れば、`var i` は関数スコープ（あるいはグローバルスコープ）に属する単一の変数スロットとして割り当てられる。ループが回るたびに `i` の値は `0` から `1`、`2`、そしてループ終了条件を満たす `3` へと書き換えられる。
生成された無名関数（クロージャ）は、その関数スコープのレキシカル環境への参照（Context Pointer）を保持し続ける。そのため、非同期処理や遅延実行によって関数が呼び出された瞬間、そこにあるのは「書き換えられきった `i = 3`」という単一のメモリ実体そのものだ。
—
2. `let` がもたらすパラダイム：イテレーションごとのレキシカル環境クローン
では、現代の標準である `let` を用いた場合、V8内部のヒープはどう変貌するのか。
// 【モダンアプローチ】letによるイテレーションごとの独立したレキシカル環境
function createAsyncTasksLet() {
const tasks = [];
for (let i = 0; i < 3; i++) {
// V8はこのループブロック単位で新しいレキシカル環境をインスタンス化する
tasks.push(function() {
console.log(`Task let: ${i}`);
});
}
return tasks;
}
const funcsLet = createAsyncTasksLet();
funcsLet.forEach(fn => fn());
// 出力結果:
// Task let: 0
// Task let: 1
// Task let: 2
ECMAScript仕様（ES2015以降の `for (let …)` の評価アルゴリズム）およびV8の内部実装（Ignition / TurboFan）において、`let i` がヘッド（ヘッダー部）で宣言された `for` ループは、単なるシンタックスシュガーではない。
V8は、ループの各イテレーション（反復）の開始時に、そのイテレーション専用の新しいレキシカル環境（Lexical Environment）をヒープ上に動的に生成（allocate）する。
V8内部のメモリレイアウトと隠しクラス（Hidden Classes / Maps）
V8は動的型付き言語であるJavaScriptを高速化するため、オブジェクトのプロパティオフセットを管理する「隠しクラス（V8用語では Map）」を動的に生成する。
`for` ループ内で `let` によって作成される変数領域も、JITコンパイルの過程において最適化され、スコープ内の変数が再代入されない（Immutableである）と静的解析（Escapes Analysis）で判定された場合、V8はこれらをヒープではなくスタックフレーム、あるいはレジスタ上に直接割り当てることがある。
しかし、上記のようにクロージャによって変数がスコープ外へキャプチャ（Escaped）された場合、話は別だ。
V8は変数をヒープ上のコンテキストオブジェクト（Context Object）へと「昇格（Heap Allocation）」させる。`let i` の場合、ループが3回回ると、ヒープ上にはそれぞれ独立した3つのコンテキストオブジェクトが生成され、それぞれが異なる `i` の値（0, 1, 2）を保持する。
[Function Context]
└── Loop Iteration 0’s Lexical Environment ──> { i: 0 } (Closure A が参照)
└── Loop Iteration 1’s Lexical Environment ──> { i: 1 } (Closure B が参照)
└── Loop Iteration 2’s Lexical Environment ──> { i: 2 } (Closure C が参照)
これが、クロージャがそれぞれの正しいイテレーションの値を保持し続けられる物理的な理由である。
—
3. ガベージコレクション（GC）とメモリリークの境界線
ここでシニアエンジニアとして懸念すべきは、「イテレーションごとに生成されるレキシカル環境のクローンは、いつ、どのようにガベージコレクション（GC）の対象になるのか」という点だ。
V8のガベージコレクタ（世代別GCである Orinoco：Minor GC / Scavenger と Major GC / Mark-Sweep-Compact）は、オブジェクトグラフの到達可能性（Reachability）を常時監視している。
クロージャによる参照保持とGCの遅延
`createAsyncTasksLet()` の例では、返された配列 `tasks` がそれぞれのクロージャを保持し、各クロージャがそれぞれのイテレーション環境（Lexical Environment）への参照（Context pointer）を保持している。
結果として、これら3つのレキシカル環境は、配列 `funcsLet` がメモリ上に存在する限り、Young Generation（新生代）からOld Generation（老世代）へ昇格しながら生存し続ける。
もしこれが数万回、数百万回の巨大な `for` ループであればどうなるか？
// 【危険な実装】巨大なループ内でのクロージャ生成によるメモリ圧迫
function processMassiveData(items) {
const handlers = [];
for (let i = 0; i < items.length; i++) {
const heavyData = items[i]; // 巨大なオブジェクト
handlers.push(() => {
// heavyData をキャプチャしているため、heavyData 全体がヒープに残留する
return heavyData.compute();
});
}
return handlers;
}
このコードでは、`let i` だけではなく、ループ内で宣言された定数や一時変数も、クロージャがスコープチェーンを共有（あるいはキャプチャ）することで、意図せずGCから保護されてしまう。
V8のJITコンパイラは、どの変数が実際にクロージャから参照されているか（Liveness Analysis）を解析し、不要な変数はコンテキストから除外しようとする（Context Specialization Optimization）が、開発者が意図しないスコープ共有を行っている場合、メモリフットプリントは確実に肥大化する。
—
4. プロファイリングとパフォーマンスの最適化
この挙動をブラウザのDevToolsや Node.jsの `–inspect` を用いたHeap Snapshotで確認すると、`Closure` 内部の `[[Scopes]]` プロパティの中に、階層化された `Script` や `Block` スコープがイテレーションごとに配列として展開されている様子が観測できる。
パフォーマンスチューニングの鉄則として、以下の指針が導き出される。
1. ループ内のクロージャ生成を避ける
高頻度で実行されるホットパス（Hot Path）内の `for` ループで毎回無名関数やアロー関数を生成し、`let` 変数をキャプチャさせると、V8のヒープアロケーションコストと将来のGCスキャンコストが劇的に跳ね上がる。
2. 必要な変数だけをスコープに閉じ込める
ループカウンタ `i` 自体は `let` で問題ないが、ループ内で重いオブジェクトを生成し、それを外に持ち出す必要がない場合は、ブロック（`{ … }`）を明示してスコープの寿命を最小化する。
// 【最適化されたパターン】スコープの寿命を局所化し、GCの回収を効率化する
for (let i = 0; i < 1000000; i++) {
// ブロックを明示的に切ることで、この中のレキシカル環境はイテレーション終了ごとに
// 次のサイクルの前にScavenger（新生代GC）の回収候補になりやすくなる
const localResult = computeSomething(i);
if (localResult.isValid) {
// 必要な場合のみ外の構造体にバインド
globalCache.set(i, localResult.value);
}
}
---
5. まとめ：ランタイムを見据えたコードを書くということ
JavaScriptは、もはや「動的で適当に書いても動くおもちゃの言語」ではない。V8という高度な仮想マシン上で稼働し、JITコンパイル、インラインキャッシュ、隠しクラス、そして洗練されたガベージコレクションのアルゴリズムの上に成り立っている厳格なシステムランタイムである。
`for` ループにおける `let` の挙動——それは単なる「ブロックスコープの実現」という仕様の表層に過ぎず、その裏ではV8が懸命にメモリ空間を分割し、クロージャの生存性を管理している。
この低レイヤのメカニズムを脳内にインプットしたエンジニアだけが、メモリリークがなく、ミリ秒単位の処理遅延（Jank）をも排除した、真に堅牢なエンタープライズアプリケーションを構築できる。言語仕様の向こう側にあるランタイムの息吹を常に感じながら、コードを紡ぎ出してほしい。