V8のオブジェクト表現と隠しクラスの遷移図

なぜ「形」を図で追うのか

V8がオブジェクトを速く扱える鍵は、値そのものと「どんなプロパティがどの位置にあるか」という形（shape）を分けて持つ点にあります。形は内部メタデータの隠しクラス（V8の用語ではMap、Shapeとも）として表現され、プロパティを足すたびに別の隠しクラスへ遷移します。この遷移は単なる連鎖ではなく、追加順序や型で枝分かれするツリーを成します。本稿はその遷移ツリーと、参照箇所ごとの**インラインキャッシュ(IC)**が劣化していく過程を、擬似コードと表で図解します。前提となるエンジン全体像は JavaScriptエンジンの内部（JITとインラインキャッシュ） と JavaScript に譲り、ここでは「形」の構造に集中します。

オブジェクトの物理レイアウト

V8のオブジェクトは1枚岩ではなく、複数の領域に分かれて配置されます。

• Map（隠しクラス）へのポインタ：先頭ワード。形・サイズ・プロトタイプ・要素種別などを指す。
• プロパティのバッキングストア：名前付きプロパティの値。固定数までは**オブジェクト内（in-object）に直接埋め込み、あふれた分は外部のプロパティ配列（out-of-object）**へ追い出す。
• 要素（elements）のバッキングストア：arr[0]のような数値添字プロパティ。名前付きとは別管理。

肝心なのは、値の置き場所（オフセット）はMapが知っていることです。obj.xは「Mapを見てxのオフセットを引き、そのワードを読む」だけになり、毎回のハッシュ探索を回避できます。Mapはプロパティ名→オフセットの記述子（descriptor）の表を持ち、同じ形のオブジェクトすべてで1つのMapを共有します。

遷移ツリー：根は空Map

空オブジェクト {} は「プロパティ0個」を表す根のMapを指します。プロパティを足すと、V8はまず「このMapからそのプロパティを足した先のMap」が既にあるか遷移テーブルを引きます。あれば再利用し、なければ新しいMapを作って遷移を登録します。こうして同じ手順を踏むオブジェクト群は、まったく同じMap列を共有します。

（遷移ツリー：矢印はプロパティ追加。M0 が根＝空オブジェクト）

M0 {} ──+x──> M1 {x} ──+y──> M2 {x,y} ──+z──> M3 {x,y,z}
   │
   └──+y──> M4 {y} ──+x──> M5 {y,x}

・makePoint(a,b){ o={}; o.x=a; o.y=b } を通る全オブジェクトは M2 を共有
・先に y を足すと M4→M5 という別の枝に入り、{x,y} とは別クラス扱い

各Mapは親へのバックポインタを持ち、ツリーは根から葉へ向かう遷移と、葉から根へ戻る逆引きの両方をたどれます。重要なのは、プロパティ集合が同じでも追加順序が違えば別のMapになる点です。{x,y}（M2）と{y,x}（M5）はプロパティ名の集合こそ同じでも、オフセット割り当てが異なる別の形として扱われます。

function makePoint(x, y) {
  const o = {};
  o.x = x;   // M0 -> M1
  o.y = y;   // M1 -> M2  ← この経路を通る全オブジェクトが M2 を共有
  return o;
}

形が壊れるとき：辞書モードへの転落

遷移ツリーで管理できるのは「素直に育つ形」だけです。次のような操作は固定オフセット表現を諦めさせ、オブジェクトを辞書モード（dictionary / slow mode）——プロパティ名をキーにしたハッシュテーブル——へ落とします。

辞書モードに落ちたオブジェクトは、参照のたびにハッシュ探索を行い、後述のICも効きません。一度落とすと自動では戻りにくいため、deleteを避け値を空にするだけでも体感差が出ます。

インラインキャッシュの劣化過程

ICは obj.x のようなアクセス箇所ごとに、「直前に来たオブジェクトのMapと、そのときのxのオフセット」を記憶します。次に同じ箇所を通ったとき、来たオブジェクトのMapが記憶と一致すれば探索を飛ばして即読みします。ICの状態は、その箇所が観測したMapの種類数で次のように遷移します。

劣化は一方向に進みます。初回アクセスで uninitialized → monomorphic となり1つの形を覚え、別の形が来るたびに分岐を増やしてpolymorphic化、種類が上限を超えるとmegamorphicへ落ちてキャッシュ自体を放棄します。

（同一アクセス箇所 obj.x の IC 状態遷移）

uninitialized ──初の形 A──> monomorphic{A}
      monomorphic{A} ──別の形 B──> polymorphic{A,B}
      polymorphic{A,B,C,D} ──5つ目の形 E──> megamorphic（学習を放棄）

function readX(o) { return o.x; }   // この o.x が1つのIC箇所

readX({ x: 1 });            // monomorphic：形 {x} を学習
readX({ x: 1 });            // ヒット、最速で読む
readX({ x: 1, y: 2 });      // 形が {x,y}（別Map）→ polymorphic 化
// …さらに {x,a}, {x,b}, {x,c} と異なる形を流すと megamorphic へ

図解からの実務指針

遷移ツリーとIC劣化を1枚に重ねると、速いコードの条件が見えてきます。

• 同じアクセス箇所には同じ形だけを通す：そのICを単型に保てる。多種の形を1つの関数に流すほど多型過多へ近づく。
• プロパティは同順で一度に初期化する：遷移ツリーが一本化し、下流のICが学習する形が1種類で済む。
• deleteせず値を空にする：辞書モードへの転落を避け、固定オフセットとICを維持できる。
• 配列は単一型で詰めて使う：要素表現の劣化（疎配列・型混在）を防ぐ。

これらが効くのはホットパス（ループ内側や毎フレーム呼ばれる関数）に限られます。まず計測でホットスポットを特定し、効く場所だけ形を整えるのが費用対効果の高いやり方です。計測の考え方は Webパフォーマンス、JavaScriptがいつ実行されるかの土台は イベントループの内部 を参照してください。

まとめ