WASM 3.0 完了

2025年9月18日原文(webassembly.org)

概要

Wasm 3.0 のリリース発表
64ビットアドレス空間 や複数メモリ、ガーベジコレクションなど大規模な新機能追加
例外処理 や 型付き参照、 テイルコール など多言語対応強化
決定論的プロファイル や カスタムアノテーション による柔軟性向上
主要ブラウザや Wasmtime などでのサポート進行中

Wasm 3.0の新機能概要

64ビットアドレス空間 ・メモリやテーブルで i64アドレスタイプ 利用可能・理論上 16エクサバイト まで拡張可能・Web上では 16GB 制限、非Web環境で大規模アプリ・データセット対応
複数メモリ対応 ・単一モジュールで 複数メモリ の宣言と直接アクセスが可能・モジュール間のデータコピーや 静的リンク ツール（wasm-merge等）への対応・セキュリティやバッファリング、計測用の分離アドレス空間活用
ガーベジコレクション（GC） ・ Wasmランタイム による自動メモリ管理領域の追加・ struct型・array型・タグ付き整数 でメモリレイアウト宣言・オブジェクトシステムやクロージャ等の高レベル機能は未搭載・各言語のコンパイラが独自にデータ表現設計
型付き参照 ・ 参照型の拡張 でヒープ値の正確な型記述が可能・ランタイムチェック不要な安全性確保・ 関数参照 にも適用、 call_ref命令 で安全な間接呼び出し実現・ サブタイピング や 型再帰 もサポート
テイルコール ・関数呼び出し時に スタック消費を抑制 ・静的/動的な呼び出し両方に対応・関数型言語や内部処理技法への最適化
例外処理 ・ ネイティブ例外処理 の導入・例外タグとペイロードデータで定義・例外のスローとタグによる選択的キャッチ・ catch-all やタグ/ラベルペアによる分岐制御
リラックスドベクター命令 ・ SIMD命令 のパフォーマンス向上目的・一部動作を 実装依存 で許容・許可された選択肢から挙動を選択
決定論的プロファイル ・ 非決定論的命令 （浮動小数点演算やリラックスドベクター命令等）に 標準動作 を規定・ ブロックチェーン やリプレイ可能システム等での 完全な決定論的実行 を保証・プラットフォーム間の再現性・移植性向上
カスタムアノテーション構文 ・Wasmテキストフォーマットで 注釈記法 追加・バイナリのカスタムセクション相当の情報を 人間可読・編集可能 に・標準自体は意味付与せず、下流標準で具体化可能

JavaScriptとの連携強化

JS string builtins拡張 ・JavaScriptのstring値を externref としてWasmに渡す機能強化・新しいプリミティブライブラリの関数で Wasm内から直接文字列操作 が可能

多言語対応とエコシステム発展

高レベル言語対応強化 ・Java、OCaml、Scala、Kotlin、Scheme、Dart等が GC機能 を活用・新しい言語のWasmターゲット化が加速
SpecTecツールチェーン での標準策定・より 信頼性の高い仕様 文書化を実現
主要ブラウザ や Wasmtime 等スタンドアロンエンジンでのサポート進行・ Wasm feature status page で各エンジンの対応状況を追跡可能

Wasm 3.0の意義と今後

大規模アプリケーション や 多様な言語 のWasm対応促進
パフォーマンス ・ 安全性 ・ 柔軟性 の向上
標準仕様の進化 によるWeb外での利用拡大
開発者・エンジン実装者 への新たな可能性

Hackerたちの意見

ガーベジコレクション。生のリニアメモリの機能を拡張するだけでなく、Wasmはガーベジコレクタを介してWasmランタイムによって自動的に管理される新しい（別の）ストレージ形式のサポートも追加します。Wasmが低レベル言語であるという精神を守りつつ、Wasm GCも低レベルです。Wasmをターゲットにしたコンパイラは、構造体や配列型、さらにアンボックスされたタグ付き整数のメモリレイアウトを宣言でき、その割り当てとライフタイムはWasmが処理します。でも、それだけです。すごい！

64ビットが仕様のデフォルト部分になるのはめっちゃ楽しみ！多くのウェブアプリがこれによって制限されてるから、特にオンラインの動画編集ツールなんかはね。Figmaでも32ビットの制限があって、いろいろと制約があるのが見える。気になるのは、モバイルデバイスがタブごとのアドレス可能メモリ制限をそのまま維持するのかどうか。これは32ビット空間に結びついているというより、OSによって定義されることが多いからね。

└

残念ながら、Memory64はかなりのパフォーマンスペナルティがあるんだ。なぜなら、wasmランタイムが境界をチェックしなきゃいけないから（32ビットの時は、ランタイムが毎回4GBのアドレス空間を全て割り当ててたから必要なかった）。でも、4GB以上のメモリが本当に必要なら、使ってもいいよ。

ウェブの制限が具体的に16GBになっているのには技術的な理由があるの？それとも、単に標準化のために選ばれた丸い数字なのかな？それに、JSのヒープサイズ（およびArrayBufferサイズ）の制限も16GBに緩和されたの？それともまだ低いまま？

コンポーネントモデルの作業（https://component-model.bytecodealliance.org/）は、3.0リリースに何か関係あるの？

└

いや、コンポーネントモデルの提案はWasm 3.0のリリースには含まれていないよ。提案がWasmのポイントリリースに入るのは、ステージ5に達したときだけだから、コンポーネントモデルはまだ開発中で、フェーズを進めようとはしていないんだ。Wasm 3.0に含まれた提案とは違って、コンポーネントモデルはコアWasmモジュールのエンコーディングやその意味に変更を加えない。代わりに、コアWasmモジュールを含む新しいエンコーディングコンテナとして設計されていて、各モジュールのインターフェースタイプや、それらのモジュールをインスタンス化してリンクする方法を説明する追加情報を加えている。これらの追加をコアWasmの外に置くことで、どんな古いWasmエンジンでも実装を構築できるし、モジュールをインスタンス化してリンクするための追加コードや、コアWasm ABIから高レベルのインターフェースタイプへの変換もできる。Jcoプロジェクトは、すべてのウェブエンジンのWasm実装で使われる共通のJSインターフェースを使って、まさにそれを実現しているよ。だから、ウェブエンジンが自分たちで作業をする必要なく、ウェブ上でコンポーネントモデルを提供できるんだ。コアWasmに変更を加える提案ではそれは不可能なんだけどね。

AssemblyScriptがWASM GCに移行するきっかけになればいいなと思ってる： https://github.com/AssemblyScript/assemblyscript/issues/2808 そこにはポリフィルを待っているコメントもあるけど、GCサポートは広く普及しているから、主要バージョンでは非GCランタイムのサポートをやめてもいいんじゃないかな。

gcについて：> Wasm GCも低レベルです。Wasmをターゲットにしたコンパイラは、構造体や配列型、さらにアンボックスされたタグ付き整数のメモリレイアウトを宣言でき、その割り当てとライフタイムはWasmが処理します。Wasmについてはすでに多くの誤解があるし、「GCをサポートしてるから、PythonやJava、C#、Goなどをエクスポートできる」と言う人が出てくるのが心配。これは魔法の解決策じゃないよ。CppやRustがまだ主流になると思う。WASMのGC機能に頼るには、WASMを生成するコンパイラの抽象化に基づいたコードを書く必要がある。

└

WASMにおけるGCの目的は、そんな高レベル言語をWASM内に置くために、重いランタイムを必要としないことだと思ってたんだけど、もしそうでないならWASM GCの価値は何なの？

└

KotlinのWasmコンパイラは、基本的にWasmのGCサポートの上に構築されているんだ。まあまあうまく動いてるよ。私の理解では、基本的には通常のJavaScriptでも使われているのと同じガーベジコレクタだね。 > これは銀の弾丸ではないよ。CppやRustがやっぱり主流になると思う。もうそれは必ずしも真実ではないと思うけど。だけど、君が言うように、使うコンパイラやそれがどれだけうまく活用されるかによるね。JetbrainsはKotlinとWasmに大きな計画を持っていて、例えばCompose Multiplatformがすでにそれをサポートしているよ（iOSネイティブやAndroidも含めて）。

└

Wasm-GCはコンパイラ作成者向けの抽象化で、GC依存の言語が既にGCされたブラウザ/Wasmヒープの中でGCを持たずに動作できるようにするものなんだ。だから、JavaやC#などはより良く動くよ（今のC#のWASMエクスポートが生成するひどい混乱を見れば、基本的に内部プラットフォームにGCを含んでるからね）。でも、明確に「javascript」オブジェクトとはやり取りしないよ（JSオブジェクトへの参照は持てるけど、JSメソッドを直接呼ぶことはできない）。

└

例えばDartでは全然違うよ。DartはWASM-GC言語だからね。Dartの一番の売りは、一度コードを書けばどこでも動くってこと。WASMはx64やRISC-V、iOSと同じようなコンパイルターゲットの一つなんだ。

Hacker Newsで議論の続きを見る

ハクソク