ブラウザのメモリ表現（文字列インターンとSmallInt最適化）

なぜ「メモリ表現」を知る必要があるのか

JavaScriptは型を意識させない言語ですが、その下でV8はすべての値をポインタサイズのワードに詰め込むという強い制約の中で動いています。なぜ小整数の足し算はGCを起こさず、なぜ巨大文字列の連結が一瞬で終わり、なぜある書き方だけメモリが膨らむのか——これらは個別の事象ではなく、値をワードにどう詰めるかという表現方式から導かれる必然です。原理を押さえれば、どのデータ構造がアロケーションを誘発するかを推測でなく仕組みから判断できます。前提として数値の表現は JavaScriptの数値表現とIEEE754が生む落とし穴 を、オブジェクトの内部形は V8のオブジェクト表現と隠しクラスの遷移図 を押さえておくとつながります。

タグ付きポインタ：1ワードに値か参照かを詰める

V8では、変数が指す1つの値はポインタサイズのワード（ポインタ圧縮環境では32bit、非圧縮では64bit）で表されます。問題は、そのワードに「整数そのもの」と「ヒープ上のオブジェクトへの参照」のどちらも入れたいことです。V8はこれを最下位ビットのタグで見分けます。

ヒープオブジェクトは必ず偶数アドレスに整列されるため、アドレスの最下位ビットは常に0です。V8はそこに1を立てて「これは参照」と印を付け、SMIには印を付けません。結果、1ワードを見るだけで分岐でき、型タグを別の場所に持つ必要がありません。これがタグ付きポインタで、SMIとHeapObjectという二系統を1ワードに同居させる土台です。

SMI：ヒープを使わない小整数の即値表現

SMI（Small Integer）は、ワードのタグ以外のビットに整数値を直接埋め込んだ表現です。ポインタ圧縮環境では32bitワードの上位31bitが値域となり、-2^30 から 2^30 - 1（約 ±10.7億）の整数がSMIとして扱われます。この範囲の整数はヒープ確保を一切伴わず、ワードの中だけで足し算・比較ができます。

（ポインタ圧縮環境・32bitワードの概念図）
[ 31bit 整数値 ][tag=0]   ← SMI：値そのもの、確保なし
[ 31bit アドレス ][tag=1] ← ヒープ参照：HeapNumberなどを指す

SMIが速いのは、メモリ確保もGC対象の増加も起きないからです。配列のインデックス、ループカウンタ、小さなIDなど、JavaScriptの整数の大半はこの範囲に収まるため、V8はそれらを実質「ネイティブの整数」のように扱えます。

boxing：SMIを外れた数はHeapNumberに箱詰めされる

SMIの値域を超える整数、そしてすべての小数（3.14 や 0.1）は、1ワードに収まりません。これらはヒープ上に HeapNumber というオブジェクトとして確保され、IEEE754倍精度の64bitをそこに格納し、変数のワードにはその参照（tag=1）が入ります。値を箱に入れて参照で持つこの操作が boxing（ボクシング） です。

let a = 100;          // SMI：確保なし、即値
let b = 3.14;         // HeapNumber：ヒープに64bit確保＋参照
let c = 2 ** 31;      // SMI範囲外 → HeapNumber
a = a + 1;            // SMIのまま、確保なし
b = b + 1;            // 新しいHeapNumberを確保（数値はイミュータブル）

boxingのコストは二重です。第一に確保そのもの（GC対象が増える）、第二に値を読むたびにポインタを追ってヒープにアクセスする間接参照です。さらにループ中で小数を更新し続けると、その都度新しいHeapNumberが生まれ、GC圧が上がります。整数で済む計算をうっかり小数化しない、配列を整数だけで詰める、といった配慮がここで効きます。

文字列インターン：同じ文字列の実体を1つに共有する

文字列側の最適化がインターン（interning）です。V8はリテラル文字列、オブジェクトのプロパティ名（キー）、識別子などをインターン化された文字列テーブルに登録し、内容が同一なら同じ実体を共有します。こうすると、同じキーが何度現れてもメモリは1つで済み、しかも比較がポインタ一致の確認だけで終わります（内容を1文字ずつ比べる必要がない）。

const k1 = "name";
const k2 = "na" + "me";   // コンパイル時に畳まれ、同じインターン実体になりうる
obj[k1] === obj[k2];      // キー比較がポインタ比較で高速

プロパティ名がインターンされることは、隠しクラス（hidden class）でプロパティを高速に解決できる前提にもなっています。動的に大量のユニークな文字列をキーにすると、インターンテーブルが膨らみ共有の利点が薄れるため、キーは安定した既知の集合に寄せるのが定石です。

ConsString と SlicedString：コピーを遅延する文字列表現

文字列はイミュータブルなので、連結や切り出しのたびに新しい連続バイト列を作ると、長い文字列ではコピーが致命的になります。V8はこれを実体コピーの遅延で回避し、文字列を複数の内部表現で持ちます。

a + b は内容をコピーせず、a と b を子に持つ ConsString という木のノードを1つ作るだけで済みます（O(1)）。同様に s.substring(i, j) は親 s への参照とオフセットだけを持つ SlicedString になり、元の文字を複製しません。だからこそ巨大文字列の連結や切り出しが見かけ上「一瞬」で終わります。

メモリ効率を意識したデータ構造選択の指針

ここまでの表現方式から、実務での選択指針が機械的に導けます。要点は「SMIとインターンが効く形に寄せ、boxingと無駄なConsStringの木を避ける」ことです。

数値が常にSMI範囲かつ小数を含まないなら、配列はSMI要素のまま軽量に保てます。固定長で型が一様な巨大データは、boxingもelements kindの格上げも起きない TypedArray・ArrayBuffer が最も密です（バイト列としての扱いは TypedArray・ArrayBuffer・DataViewのメモリレイアウト）。文字列の組み立ては、都度 += するより配列に貯めて最後に join で一度だけ平坦化するほうが、ConsStringの木とGCを抑えられます。

まとめ