WebAssemblyの実行モデルとJSとの境界

なぜWasmは速く、なぜ境界で遅くなるのか

WebAssembly（Wasm）は「ブラウザで動く速いバイナリ」と紹介されがちですが、それだけでは「どこが速くて、どこに落とし穴があるか」を説明できません。速さの源泉は、Wasmが事前に型が確定した検証済みの命令列であり、エンジンが推測をせずに機械語へ落とせる点にあります。一方で、Wasmは単独で完結せず、DOM操作や外部APIには必ずJavaScriptを経由します。このJS↔Wasm境界を頻繁にまたぐと、変換と呼び出しのコストが積み上がり、せっかくの速さが相殺されます。原理を押さえると、Wasmを「使えば速い道具」ではなく「境界設計しだいで速くも遅くもなる仕組み」として扱えます。

型付きスタックマシン：推測しない実行モデル

Wasmの命令はスタックマシンとして定義されます。レジスタを名前で指定するのではなく、オペランドを暗黙のスタックに積み、命令がスタックの頂上から値を取り出して結果を積み直します。たとえば local.get 0、local.get 1、i32.add という3命令は、「ローカル変数0と1をスタックに積み、加算して結果を積む」という意味になります。

重要なのは、各命令の入出力の型が静的に決まっていることです。i32.add は必ず2つの i32 を取り i32 を返します。値型は当初 i32 / i64 / f32 / f64 の4つで、後に参照型（funcref / externref）や128ビットの v128（SIMD）が加わりました。ロード時の**検証（validation）**で、スタックの型整合・到達可能性・境界が静的に保証されるため、エンジンは実行時に「この値は整数か？」と推測する必要がありません。

スタックマシンは概念モデルであり、実機がスタックを愚直に上下させるわけではありません。エンジンは検証済みのバイトコードをSSA形式の内部表現に変換し、ローカルやスタック上の値を実レジスタへ割り付けて機械語を生成します。スタック表現は「コンパクトで検証しやすいエンコード」を担い、実行性能はその後のコンパイラが受け持ちます。

線形メモリ：1本の連続バッファという制約

Wasmのメモリは線形メモリ（linear memory）と呼ばれる、バイト単位でアドレス可能な連続した1本のバッファです。JS側からはこれが WebAssembly.Memory として見え、その実体は ArrayBuffer です。Wasmのロード/ストア命令はこのバッファ内のオフセットを読み書きし、範囲外アクセスは検証ではなく実行時の境界チェックでトラップ（例外）になります。これがWasmの「サンドボックス」の核で、ホストのメモリ空間を直接触ることはできません。

ここから、JSとの相互運用における最大の制約が導かれます。Wasmが直接扱える値は数値（と参照）だけで、文字列・配列・オブジェクトといった構造を持つデータは、線形メモリ上のバイト列として表現し、そのオフセットと長さを数値でやり取りするしかありません。

// JS文字列をWasmへ渡す典型パターン（概念）
const bytes = new TextEncoder().encode("こんにちは");
const ptr = wasm.exports.alloc(bytes.length);      // Wasm側でメモリを確保
const mem = new Uint8Array(wasm.exports.memory.buffer);
mem.set(bytes, ptr);                               // バッファへコピー
wasm.exports.process(ptr, bytes.length);           // オフセットと長さを渡す

つまり「文字列を渡す」は、内部的にはエンコード＋線形メモリへのコピー＋ポインタ受け渡しです。オブジェクトをそのまま値として渡す手段はありません。なお、memory.grow でバッファを拡張すると ArrayBuffer が再確保されて古いビューが無効化される（detach）ため、memory.buffer を握りっぱなしにせず、拡張後は Uint8Array を取り直す必要があります。

JS↔Wasm境界の本当のコスト

「Wasmは速い」という言明は、関数の内部計算については正しい一方、境界をまたぐ行為には当てはまりません。境界コストは主に次の3つに分解できます。

最新のエンジンは引数も戻り値も数値の単純な呼び出しを大きく最適化しており、純粋な呼び出しコスト自体は年々下がっています。それでも、境界を細かく多数またぐ設計は損です。たとえば配列の各要素ごとにWasm関数を呼ぶより、配列全体を線形メモリに置いて「一括処理する1関数」を呼ぶほうが、呼び出し回数も変換も激減します。原則は明快で、境界は粗く（chunky）、内部は細かくです。

DOMを直接触れない点も設計に影響します。Wasmは仕様上ホスト関数（インポート）越しにしか外界へアクセスできず、document 等の操作は必ずJSのグルーコードを通ります。externref は不透明なホスト参照を数値化せずWasm内で保持できるため、JSオブジェクトのハンドルをコピーせず受け渡せますが、その実体を操作するにはやはりJS側の関数が要ります。

ストリーミングコンパイルとJITの関係

Wasmの起動が速いもう一つの理由が、コンパイル戦略です。WebAssembly.instantiateStreaming(fetch(url)) を使うと、エンジンはダウンロードと並行してバイナリを検証・コンパイルします（ストリーミングコンパイル）。バイト列が届いた端から関数単位で処理できるため、全体のダウンロード完了を待ってからコンパイルを始める場合より、最初のコードが動くまでの時間が短くなります。これがWasmを ArrayBuffer から同期的に作るより推奨される理由です。

エンジン内部では、起動と最終性能を両立させるため二段（ティア）コンパイルが一般的です。

考え方はJSエンジンのJITと似ていますが、出発点が異なります。JSは動的型ゆえ「実行時に観測した型」を前提にしますが、Wasmは型がすでに確定しているため、第1ティアでも推測なしで正しい機械語を出せます。そのうえで頻繁に実行される関数を第2ティアで最適化し、関数を裏で差し替えます（ティアアップ）。Wasmにおける「JIT」は、JSのような型推測の意味は薄く、起動の速い浅い最適化から、重い深い最適化へ段階的に移すための仕組みと理解するのが正確です。

まとめ