【テクニカル・上級編】V8エンジンにおける変数の格納場所：スタックメモリとヒープメモリの使い分け – JavaScriptコア文法・モダン言語仕様と変数・関数解析バイブル

V8の深淵：プリミティブと参照型が辿るメモリ空間の物理的運命

JavaScriptのコードを書くとき、私たちはしばしば「変数に値を代入している」という抽象的なメンタルモデルで思考しがちだ。しかし、V8エンジン（あるいは任意のモダンJSランタイム）の視座に立てば、それは全く異なる現実として映る。

コードベースの1行、`const x = 42;` や `let obj = { a: 1 };` は、V8のパーサーによって抽象構文木（AST）に変換され、Ignition（バイトコードインタープリタ）を経て、TurboFan（JITコンパイラ）の最適化パイプラインに晒される。その過程で、変数が「どこに格納されるか」は、単なるメモリアロケーションの問題ではなく、CPUキャッシュのヒット率、JITのインラインキャッシュ（ICs）の効率、そしてガベージコレクション（GC）のレイテンシを決定づける極めて物理的な問題なのだ。

本稿では、V8エンジンがプリミティブ型と参照型をどのようにスタックメモリとヒープメモリへ振り分け、どのような最適化とGCの洗礼を与えているのか。そしてその低レイヤの挙動が、セキュリティの脅威（プロトタイプ汚染）とどう交錯するのかを、チーフアーキテクトの視点から解き明かす。

—

1. スタックとヒープの物理的実態：V8ヒープのアーキテクチャ

よくある誤解として、「プリミティブ型は常にスタックにあり、オブジェクトは常にヒープにある」という説明がまかり通っている。しかし、V8の内部実装（C++によるV8 C++ APIおよびオブジェクト表現）において、この境界線はもっとダイナミックかつ実利主義的だ。

プリミティブの正体：SMIとHeapNumber

V8では、数値（Number）は極めて戦略的に扱われる。

  • SMI (Small Integer): 31ビット（64ビットアーキテクチャの場合はポインタ圧縮によりさらに効率化される）の符号付き整数は、ヒープ上のオブジェクトとしてアロケートされず、直接ポインタのビットパターンの中に値そのものが埋め込まれる（即値表現）。これはスタック（またはレジスタ）上に存在し、GCの追跡コストが完全にゼロである。
  • HeapNumber / BigInt / String: 範囲外の浮動小数点数や巨大な文字列、BigIntは、ヒープメモリ上に専用の構造体としてアロケートされる。したがって、これらは「プリミティブ型」という言語仕様上の分類でありながら、メモリ上ではヒープの住人となる。

参照型とスコープのライフサイクル

一方、オブジェクトや配列などの参照型は、例外なくヒープ（通常はNew Space、あるいはOld Space）にアロケートされる。スコープ内で宣言された `const obj = { x: 10 }` というコードを考えてみよう。

ここでスタック上に存在するのは、「ヒープ上のオブジェクト実体へのメモリアドレス（ポインタ）を保持するスロット」に過ぎない。関数が実行され、変数がブロックスコープに入ると、スタックフレームが拡張され、そのポインタ分の領域が確保される。しかし、オブジェクト本体はヒープという広大な空間に散らばっている。

function allocateMemoryChaos() {
// 31ビット以内の整数はSMIとしてスタック（レジスタ）上で完結する可能性がある
const stackSmi = 42;

// 巨大な文字列はプリミティブであってもV8ヒープ（New Space）にアロケートされる
const heapString = “A”.repeat(10000);

// オブジェクト本体はヒープへ。スタックにはその参照アドレスが乗る
const heapObject = { id: 1, data: heapString };

return heapObject;
}

// この関数の実行後、stackSmiはスタックフレームの崩壊と共に一瞬で消滅するが、
// heapObjectとその内部のheapStringはGCが回収するまでヒープを占有し続ける。
const retainedRef = allocateMemoryChaos();

—

2. JITコンパイルと隠しクラス（Hidden Classes / Maps）の物理最適化

JavaScriptの動的な性質は、本来であればメモリレイアウトの静的な最適化を不可能にする。どのオブジェクトがどのプロパティを持つか実行時に変わるからだ。しかし、V8は「隠しクラス（V8用語では Map）」という概念を導入することで、これを解決している。

インラインキャッシュ（IC）とプロパティアクセス

次のようなコードを考えてほしい。

function Point(x, y) {
this.x = x;
this.y = y;
}

const p1 = new Point(1, 2);
const p2 = new Point(3, 4);

V8は、`p1` と `p2` が同じコンストラクタから生成された瞬間、同一の Map（隠しクラス） を共有させる。この Map は、「プロパティ `x` はオフセット 0 の位置にあり、プロパティ `y` はオフセット 1 の位置にある」というメタデータを保持している。

TurboFanがこのコードをJITコンパイルする際、この Map の構造が変化していない（Monorphicである）と判断すると、プロパティアクセスを「ハッシュマップからの動的キー検索（$O(N)$）」から、「メモリ上の固定オフセットへのダイレクトアクセス（$O(1)$）」へとマシン語レベルでコンパイルし直す。これが、静的言語に匹敵するJSの高速実行を支える核心である。

しかし、ここで不用意にオブジェクトの構造を汚染するとどうなるか？

p1.z = 5; // p1だけに後からプロパティを追加

この瞬間、`p1` は新しい Map（隠しクラス）へと移行（Transition）させられる。JITは「ポリモーフィック（複数の型が混在）」であると検知し、最適化を解除（Deoptimization）。メモリ上での物理的なオフセットアクセスが崩壊し、実行速度は急降下する。

—

3. ガベージコレクションの挙動：ScavengerとMark-Sweep-Compact

V8のヒープ管理は、世代別ガベージコレクション（Generational GC）に基づいている。メモリ効率とレイテンシの極限を追求したこのメカニズムは、変数のスコープとライフサイクルに直接依存している。

1. New Space (Scavenger / Cheneyのアルゴリズム):

  • 新しく生成されたオブジェクトや文字列は、まずここに置かれる（From空間）。
  • マイナーGC（Scavenge）が走ると、生存しているオブジェクトだけがTo空間へ高速にコピーされ、From空間は一瞬でリセットされる。
  • 短命な変数（ブロックスコープ内で使い捨てられるオブジェクトなど）は、この領域で消え去るため、コストが極めて低い。

2. Old Space (Mark-Sweep-Compact):

  • マイナーGCを何度も生き延びた老いたオブジェクトは、Old Spaceへ昇格（Promotion）する。
  • ここでは、メモリの断片化を防ぐためのコンパクション（圧縮）を伴うため、GCのコスト（Stop-the-Worldの遅延）が跳ね上がる。
  • グローバル変数や、クロージャによって意図せず参照が維持され続けたオブジェクトは、Old Spaceを圧迫し続け、メモリリークの温床となる。

—

4. セキュリティの深層：プロトタイプ汚染がRCEを誘発するメカニズム

メモリの物理構造とV8の内部挙動を理解した者にとって、「プロトタイプ汚染（Prototype Pollution）」という脆弱性がなぜ致命的なのか、その解像度は劇的に変わる。これは単なる「オブジェクトの汚染」ではなく、V8のメモリ空間とインラインキャッシュ、そしてランタイムの実行フローを根底から乗っ取るハックである。

脆弱性の本質

再帰的なマージ関数やディープクローン処理において、外部からの不審な入力をサニタイズせずに処理すると、`__proto__` や `constructor.prototype` を通じて、組込みの `Object.prototype` が改ざんされる。

// 攻撃者が送信する悪意のあるJSONペイロードの概念
const payload = JSON.parse(‘{“__proto__”: {“polluted”: “RCE_TRIGGERED”}}’);

// 脆弱なマージ関数（簡易版）
function merge(target, source) {
for (let key in source) {
if (typeof source[key] === ‘object’ && source[key] !== null) {
if (!target[key]) target[key] = {};
merge(target[key], source[key]);
} else {
target[key] = source[key];
}
}
}

// 実行
const maliciousObj = {};
merge(maliciousObj, payload);

// この瞬間、アプリケーション内のすべてのプレーンオブジェクトが汚染される
console.log({}.polluted); // => “RCE_TRIGGERED”

なぜこれがランタイムの防壁を突き破るのか？

1. インラインキャッシュの欺瞞:
V8のJITは、プロパティアクセス時にプロトタイプチェーンを辿る最適化を行う。`Object.prototype` が汚染されると、本来存在しないはずのプロパティがすべてのオブジェクトのチェーン上に突如出現する。これにより、コードのあちこちで前提条件（Invariants）が崩れ、想定外の分岐が実行される。
2. サプライチェーン汚染とRCE (Remote Code Execution):
Express.jsのルーティング処理、テンプレートエンジン（HandlebarsやEJSなど）、あるいはORMのクエリ構築ライブラリが、内部で `Object.prototype` のプロパティを安全なものと仮定して参照している場合、プロトタイプ汚染によってオプションが書き換わる。
例えば、テンプレートエンジンの設定オブジェクト（`settings`）が汚染され、デバッグモードや任意のコード実行を許可するフラグが強制的に有効化された場合、攻撃者はリモートから任意のコードをV8のコンテキスト上で実行（RCE）することが可能になる。

—

5. チーフアーキテクトからの提言：防衛的プログラミングとメモリの神髄

V8ランタイムの挙動を熟知したシニアエンジニアとして、私たちが書くべきコードの指針は明確だ。

1. スコープの寿命を最小化せよ:
変数の生存期間（Lifespan）が短いほど、V8はNew Space内で効率的に処理し、マイナーGCで瞬時に回収できる。不必要にスコープを広げた変数や、グローバルスコープへのオブジェクトのぶら下げは、Old Spaceの肥大化とGCレイテンシの増大を招く。
2. 隠しクラスの破壊を避けよ:
コンストラクタや初期化フェーズ以降に、オブジェクトへ動的にプロパティを追加・削除するな。どうしても動的な構造が必要な場合は、`Map` や `Set` を使用せよ。これらはハッシュテーブルとして明示的に最適化されており、隠しクラスの過剰なトランジションによるDeoptimizationを防ぐ。
3. プロトタイプ汚染への鉄槌:
外部入力を扱うすべてのレイヤーで、オブジェクトの拡張を禁止する `Object.freeze()` や、プロトタイプを持たないオブジェクトの生成（`Object.create(null)`）を徹底せよ。

JavaScriptは「手軽なスクリプト言語」ではない。それは、高度に最適化された仮想マシン上で稼働する、極めてアグレッシブなランタイムシステムである。その物理的な挙動を脳内にトレースできたとき、あなたの書くコードは、バグや脆弱性を寄せ付けない、圧倒的な堅牢性とパフォーマンスを手に入れることになる。

スポンサーリンク
タイトルとURLをコピーしました