V8の深淵とマルチスレッドの境界：SharedArrayBufferとAtomicsがもたらすスコープの崩壊と調停
JavaScriptは、長年にわたり「シングルスレッドの非同期言語」という安全な神話の上に築かれてきました。イベントループ、マクロタスク、マイクロタスクキュー。これらはすべて、メモリ空間への排他制御をプログラマの意識から隠蔽し、UIの整合性を保つための見事な抽象化のレイヤです。
しかし、Web Workersの登場、そして何よりも `SharedArrayBuffer` と `Atomics` の導入により、そのパラダイムは根本から覆されました。私たちは今、ブラウザのタブやNode.jsのワーカープールを跨ぎ、同じ物理メモリ空間をミリ秒単位で奪い合う「真の並行処理（Concurrency）」の時代を生きています。
本稿では、V8エンジンのメモリ管理、JITコンパイルの最適化仮説、そしてマルチスレッド環境におけるスコープの概念がどのように変質するのかを、低レイヤの視点から解き明かします。
—
1. 抽象化の崩壊：メモリ共有と「スコープ」の再定義
従来のJavaScriptにおけるスコープ（Lexical Scope）は、静的なコード構造によって決まりました。変数は特定の実行コンテキストに紐付けられ、クロージャを通じて安全にカプセル化されます。
しかし、`SharedArrayBuffer`（SAB）を介したWorker間通信において、このスコープの境界線は物理的に消滅します。
// メインスレッドまたはWorkerスレッドのコンテキスト
const sab = new SharedArrayBuffer(1024);
const int32View = new Int32Array(sab);
// スレッドAとスレッドBは、同じ物理メモリ（sab）を同時に読み書きする
ここで重要なのは、「変数への代入」と「メモリの書き換え」が切り離される点です。JavaScriptのコード上では別々のスレッドで別々の変数名（例: `workerA_var` と `workerB_var`）として扱われていたとしても、それらが同一の `SharedArrayBuffer` のオフセットを指している場合、そこにはもはや言語レベルのスコープガードは存在しません。
V8エンジンのヒープ（Heap）内において、SABが指し示す領域は、ガベージコレクション（GC）の管理下から切り離された「生（Raw）のArrayBuffer backing store」です。V8のヒープ外（Off-heap）に確保されたこの領域には、オブジェクトの隠しクラス（Hidden Classes / Maps）やインラインキャッシュ（IC）の恩恵はありません。あるのは純粋なバイト列だけです。
—
2. V8最適化の罠：JITコンパイルとデータ競合（Data Race）
V8のIgnition（インタープリタ）とTurboFan（JITコンパイラ）は、コードの実行プロファイルから型を推論し、アグレッシブな最適化を行います。しかし、SABが絡むコードでは、この最適化が致命的なバグを引き起こす温床となります。
メモリの並び替え（Memory Reordering）とコンパイラ最適化
CPUやJITコンパイラは、シングルスレッドの実行結果が変わらない範囲で、命令の実行順序を自由に入れ替えます（Out-of-Order Execution）。例えば、以下のようなコードがあったとします。
// スレッド1
sharedData[0] = 42;
isReadyFlag[0] = 1;
CPUやコンパイラの最適化により、これが逆の順序で実行される可能性があります。つまり、`isReadyFlag[0] = 1` が先に書き込まれ、その直後に他のスレッドがデータを読み取ると、`sharedData[0]` にはまだ古いゴミデータが入っているという現象が起きます。これがデータ競合です。
シングルスレッドの世界では、イベントループとマイクロタスクキューの厳密な順序制御（例：Promiseの解決はコールスタックが空になってからマイクロタスクキューを消化する挙動）によって守られていましたが、マルチスレッド環境ではCPUキャッシュのコヒーレンシ（MESIプロトコルなど）とスレッド間の可視性（Visibility）を明示的に制御しなければなりません。
—
3. Atomicsによる調停：順序性と不可分性（Atomicity）の担保
データ競合を防ぎ、スレッド間のスコープ（メモリ領域）を安全に調停するために存在するメカニズムが、`Atomics` APIです。
`Atomics` は、単なるロック機構ではありません。CPUのバスロックやメモリバリア（Memory Barrier / Fence）命令を直接JavaScriptから発火させるための低レイヤインターフェースです。
以下に、`SharedArrayBuffer` と `Atomics` を用いた、安全なロックフリーのシグナリング（通知）機構の実装を示します。
// — 共有メモリの初期化 (メインスレッド等) —
// 0番地: データ領域
// 1番地: 同期用フラグ（ミューテックス/ステータス）
const sab = new SharedArrayBuffer(8);
const i32 = new Int32Array(sab);
// — スレッドA（生産者: Producer） —
function produceData(id, value) {
// データの書き込み
i32[0] = value;
// Atomics.store を使用して、書き込みの順序と可視性を保証する
// 第3引数の軸（Atomics.store）はシーケンシャル一貫性を持つメモリバリアを生成する
Atomics.store(i32, 1, id);
// 待機している他のスレッドを起こす
Atomics.notify(i32, 1, 1);
}
// — スレッドB（消費者: Consumer） —
function consumeData() {
while (true) {
// フラグが更新されるまでスレッドをアトミックにブロックする
// ブラウザのメインスレッドでこれを呼ぶとフリーズするため、必ずWorker内で実行すること
Atomics.wait(i32, 1, 0);
const currentId = Atomics.load(i32, 1);
const data = i32[0];
console.log(`受信したデータ: ${data} (ID: ${currentId})`);
// 状態をリセット
Atomics.store(i32, 1, 0);
break;
}
}
Atomicsの挙動とランタイムの深層
`Atomics.wait()` や `Atomics.store()` が実行されるとき、V8は内部でOSのプリミティブ（Linuxであれば `futex` など）を呼び出し、スレッドをカーネルレベルでサスペンド（またはビジーループによる最適化）させます。
これにより、CPUコアが無駄なサイクルを消費するのを防ぎつつ、メモリスコープへのアクセス順序を厳密に直列化（Serialize）します。TurboFanは、`Atomics` メソッドが使われている箇所に対しては、不適切なメモリ順序の最適化を行わないよう、コード生成時に強制的なフェンス命令（`mfence` 等）を挿入します。
—
4. セキュリティとランタイム防壁：Spectre脆弱性とSABの復活
ここで、セキュリティ研究者およびアーキテクトが絶対に知っておかなければならない「暗い歴史」と「現在の防壁」について触れておきます。
2018年、CPUの投機的実行（Speculative Execution）を利用したサイドチャネル攻撃「Spectre」が発見された際、高精度なタイマーと `SharedArrayBuffer` を組み合わせることで、ブラウザの同一オリジンポリシー（Same-Origin Policy）を完全にバイパスし、他のドメインのメモリ空間から機密データを読み取ることが可能であることが証明されました。
これを受け、主要ブラウザベンダーは一斉に `SharedArrayBuffer` を無効化しました。
現在、SABが再び利用可能になっているのは、ブラウザ側が厳格なCOOP（Cross-Origin-Opener-Policy）とCOEP（Cross-Origin-Embedder-Policy）というHTTPヘッダーの付与を義務付けたからです。
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
この防壁がない環境でSABを生成しようとすると、JavaScriptランタイムは即座に `TypeError` をスローします。サプライチェーン攻撃において、悪意あるスクリプトがプロトタイプ汚染（Prototype Pollution）等を通じてグローバルオブジェクトを改ざんし、不正なWorkerを起動して機密データをスニッフィングしようとした場合でも、このCOOP/COEPの防壁と、`Atomics` による厳密なメモリ保護が機能していれば、物理的なメモリの不正読み出し（Arbitrary Memory Read）を防ぐ最後の砦となります。
—
結びにかえて
JavaScriptにおける `SharedArrayBuffer` と `Atomics` の登場は、この言語を「安全な高水準スクリプト言語」から、「ハードウェアの限界に直結するシステムプログラミング言語」の領域へと押し上げました。
スコープはもはやコード上の論理的な境界ではなく、CPUキャッシュ、メモリバス、そしてオペレーティングシステムのプリミティブと直接対話するための物理的な境界です。この領域を扱うアーキテクトには、V8のヒープ構造、JITの最適化モデル、そしてハードウェアのメモリ一貫性モデルに対する深い洞察が求められます。
抽象化の恩恵にあぐらをかくことなく、ランタイムの足音を聞き分けること。それこそが、極限のパフォーマンスと堅牢性を両立する唯一の道なのです。