Wasm 3.0 完成

 (webassembly.org)
17 ポイント 投稿者 GN⁺ 2025-09-18 | 2件のコメント | WhatsAppで共有
  • Wasm 3.0 標準が正式に発表され、6〜8年にわたって準備されてきた大規模な機能群が含まれる
  • 64ビットアドレス空間、ガベージコレクション、型付き参照、テールコール、例外処理 などにより、高水準言語を Wasm により容易にコンパイルできるようになる
  • 中核となる新機能は、高性能アプリケーション、多様な言語ランタイム、安全性と拡張性に役立つ
  • Web 環境以外の非Webエコシステムでも、より大きな容量やデータセットを扱うケースに適している
  • すでに主要な Web ブラウザでサポートされており、Wasmtime のような独立エンジンでもまもなく完成予定で、Wasm は汎用実行プラットフォームとしてさらに定着していく見込み

Wasm 3.0 リリース概要

  • WebAssembly 標準の 3.0 バージョンが 2025年9月17日にリリース
    • 2.0 バージョン（2022年完了）がベクター命令、バルクメモリ操作、複数戻り値、単純な参照型を導入してから3年ぶりの主要アップデート
    • W3C コミュニティグループとワーキンググループが開発を継続しており、今回のリリースは6〜8年かけて準備された大型機能を含むかなり大規模な変更
    • Wasm は低水準言語としての思想を維持しつつ、メモリと型システムを強化して 高水準言語のコンパイルをよりよく支援
  • 2.0 バージョン以降に開発された機能群が仕上がり、Live 標準として定着し、Web ブラウザと独立エンジンでのサポートが拡大

主な変更点と新機能

  • 64ビットアドレス空間
    • メモリとテーブルを i64 型で宣言できる
    • Wasm アプリケーションのアドレス空間が約4GBから物理的限界まで（理論上は16エクサバイト）拡張可能
    • Web では 16GB 制限が適用されるが、非Webエコシステムでは大規模アプリケーションやデータセットのサポートに有用
    広告
  • マルチメモリ
    • 単一モジュール内で 複数のメモリオブジェクトを宣言し、直接アクセスできる
    • モジュール統合やアドレス空間分離、バッファリング、セキュリティなどさまざまな用途がある
    • wasm-merge のような静的リンクツールがすべての Wasm モジュールで使えるようになる
  • ガベージコレクション (GC)
    • 線形メモリに加えて、Wasm ランタイムが自動管理するストレージをサポート
    • コンパイラは struct/array 型や unboxed 整数などのデータレイアウトを直接宣言する
    • メモリ管理の基本的なビルディングブロックのみを提供し、高水準オブジェクトシステムやクロージャは実装言語ごとに個別設計できる
  • 型付き参照
    • Wasm 型システムが拡張され、ヒープ値の形状と関数参照をより正確に記述できる
    • サブタイピングと型再帰をサポートし、新しい call_ref 命令によって ランタイム型チェックなしで安全な間接関数呼び出しが可能
  • テールコール
    • 既存関数のスタック領域を追加消費せず、即座に戻る tail call 構造をサポート
    • 関数型言語やランタイム内部最適化などに活用できる
    広告
  • 例外処理
    • Wasm 内でネイティブの 例外処理システムを導入
    • 例外タグとペイロード宣言、選択的 catch、ブロック単位の例外ハンドラを提供
    • これまで JS で迂回していた非効率な方法を使わずに 移植性と性能を改善できる
  • relaxed ベクター命令
    • SIMD 命令のハードウェア差異に対応するため、一部命令の詳細動作を実装の自由に委ねる relaxed variant を提供
    • 合法的な動作集合の範囲内で多様な最適化が可能
  • 決定論的プロファイル
    • 同一命令でも結果が非決定的になりうる状況（浮動小数点演算、relaxed SIMD など）においても、プラットフォーム間で決定論的な実行を定義
    • ブロックチェーンや再現可能なシステムなどで 再現性と移植性を保証できる
  • カスタムアノテーション構文
    • ソースコード内で人間が読み書きできる アノテーション構文を追加
    • 標準が直接解釈するものではないが、今後の標準や拡張実装に活用できる
広告

JavaScript 連携と互換性

  • JS string builtins
    • JS の文字列値を externref として Wasm に渡して操作できる
    • 新しい組み込み関数を import することで、Wasm 内部から直接外部の JS 文字列を使える

Wasm 3.0 の有用性と展望

  • 高級プログラミング言語の Wasm ターゲットコンパイルに不可欠な基盤を提供
  • Java、OCaml、Scala、Kotlin、Scheme、Dart など主要言語でも GC 機能の活用が本格化

仕様策定と配布状況

  • Wasm 3.0 は新しい SpecTec ツールチェーンで初めて作成された標準
  • 大半の 主要 Web ブラウザですでに Wasm 3.0 をサポートしており、Wasmtime などのスタンドアロンエンジンもまもなく完成予定
  • Wasm feature status ページで各エンジンごとの対応状況を確認可能

関連記事

2件のコメント

 
coremaker 2025-09-18

インメモリDBを作ろうという試みも出てくるのではないでしょうか？
 
GN⁺ 2025-09-18
Hacker Newsの意見

  • 64ビットが仕様のデフォルトになるのは本当に楽しみな点だ。特にオンライン動画エディタのようなWebアプリは、32ビットの限界のせいで今でもさまざまな制約を強く受けている。Figmaでもこうした制約を実際に経験している。ひとつ気になるのは、モバイル端末でタブごとのアドレス指定メモリ制限がそのまま維持されるのかどうかだ。通常はOSによって定義されているので、32ビット空間と直接結びついていない可能性もある

    • Video editorのようなアプリがドキュメントブラウザに入り込むのが正しいのか疑問だ。よくできたネイティブOSがあるのに、今では誰も使わなくなっているのが残念だ。もし既存OSのプロセスが与える仮想化よりさらに強力な仮想マシンが必要なら、最初から目的に合った抽象化を設計するのが正直だと思う。単純なドキュメントリーダーを無理やり動画エディタに改造しているように感じる

    • 残念ながらMemory64機能にはかなりの性能ペナルティがある。従来の32ビットではランタイムが毎回4GB全体を割り当てていたので境界チェックが事実上不要だったが、64ビットでは境界を直接確認しなければならないためだ。4GB超のメモリがどうしても必要なら使うしかない

    • GC、参照型、JS string APIが導入されるのも楽しみだ。久しぶりにうれしいJだ、元気にしているのか気になる

    • Webアプリが4GiBのメモリ上限に阻まれるのは当然にも見える。今やメールを読むのに512GiBが最低限必要な世界という感じだ

  • ガベージコレクションが追加されるのは本当に驚きだ。これまではWasmからスタックに直接アクセスできなかったので、スタックスキャンのような伝統的なGCアプローチは不可能だった。そのおかげで低レベル言語としての性格を保ちながら、struct、array型、unboxed tagged intなどでメモリレイアウトを明示し、割り当てと寿命管理はWasmが処理する。ここまでだ。感嘆するしかない

    • GCが導入されつつ、非GC環境まで含めてすべて対応する構造なのが新鮮だ。この点はD言語に似ている（Dは非GCとGCの両方で高速なコンパイル・実行をサポートする）。ちなみにDlangコンパイラのLDCでも今はWasmを生成できる Generating WebAssembly with LDC

    • この変化でWebAssembly.Memoryオブジェクトの縮小が可能になるのか気になる。メモリを解放してもブラウザに割り当てられたまま残る点で非常に重要な問題だ イシュー1 イシュー2

  • WASMがDOMを直接操作できるようになるのはいつなのか気になる。これが本来WASMの中核的な目的のように思えたが、今ではWebとほとんど関係のない別個の怪物のようにも感じる。JavaScriptをいつ頃使わなくて済むようになるのだろうか

    • この点とマルチスレッド対応がきちんとサポートされてほしい。Rustアプリをwasmにコンパイルして、下のようにそのまま呼び出したい:

      高性能Webアプリやブラウザ拡張ではメモリや性能の問題が実際に大きいので、これはとても助けになるはずだ。wasmベースのアプリならv8を飛ばしてwasmerのようなエンジンも直接使える。Web技術がElectronのようなデスクトップアプリに使われるのは、デスクトップAPIがあまりに貧弱で移植性がないからだと思う。WASMのネイティブサポートが強化されれば、Slack、VSCode、Discordのようなアプリもさらに軽くできるかもしれない

    • 今でもWASMプログラムからDOMアクセスは可能だ。ただし既存のJS APIを経由する必要があり、かつてWASM専用APIも議論されたが、欠点が多くなって結局廃案になった

    • 設計の良いフロントエンド言語を待ちながら様子を見ている。ただ、DOMにアクセスするときにJSラッパーを通るのがそこまで非効率なのかは疑問だ。大半のコードはすでに非効率なので、ここで生じるオーバーヘッドは実際にはそれほど目立たないと思う

    • JavaScriptに問題があると思うなら、DOMのほうはさらに深刻だと分かるはずだ

    • DOM参照を持つと、ガベージコレクト可能なオブジェクトを直接のぞき込めるようになる点が厄介だ。WebのJavaScriptセキュリティモデルではGC内部をのぞき見できてはならないが、もしWASMがDOMへのポインタを持てるなら、それをどう扱うかが問題になる。GCがきちんと導入された後なら再び議論できるかもしれないが、GCのないWASMではほとんど解がない問題に見える

  • 1年ほどWASM開発を追っていなかったので、バージョンごとのリリースモデルに移行していたのを今知った。いろいろな機能がオプションのまま残ると思っていたが、今ではあるバージョン互換だと言うには、すべての実装がその機能一式をサポートしていなければならないようだ（WASM 3.0など）。次にWASM 3.0を完全サポートするnon-browserランタイムが誰になるのか気になる。最初はwasmtimeだと思う（denoはv8ベースなので除外）。GCは特に厄介な機能に感じる。3.0リリースが従来の「evergreen」モデルとどうつながるのか知っている人はいるだろうか。evergreenは標準草案を継続的に更新し、正式な最終版を別に置かないモデルだ。現在の最新Candidate Recommendation Draftが事実上の標準と見なされている wasm featureの現状 wasm 2.0のニュース 最新の標準草案

    • wasmtimeはすでにwasm 3.0の主要機能をすべてサポートしている。GCは同僚のNick Fitzgeraldが数年前に実装し、tail callは昨年Jamey SharpとTrevor Elliottが完全な範囲で実装した（シグネチャ制限なし、トランポリン不要）。例外処理も出ており、まもなく正式リリース予定だ。「3.0」というリリースは、エンジンごとに各機能をすでに準備してきたという合図だと見ればよい。私はwasmtimeとCraneliftのメンテナーだ

    • Wizardは研究用ツールだが、Wasm 3.0をすべてサポートしている。ただしインタプリタとbaselineコンパイラしかなく、v8やwasmtimeのような最適化コンパイラはない。なので速度自体は遅い

    • バージョン管理はJavaScriptのfeature set方式のようになる気がする。つまり各ランタイムがどの機能セットをサポートするかで語られるようになる。wasmでfeature discovery（機能検出）がどう動くのか気になる

  • GC対応が追加されたのは本当にうれしい。以前はWASMからスタックに直接アクセスできず、伝統的なstack scanning方式のGC実装は事実上不可能だった

  • WebAssemblyコミュニティは開発者体験（DX）をもっと気にしたほうがよいと感じる。実際にコンパイラをひとつ書いてWasmをターゲットにしてみたが、かなり不便だった。形式化された意味を持つ言語だと思っていたのに、実際にはBinaryen.jsでWasmを生成する過程で明確な命令セットをターゲットにしている感覚があまりなかった。たぶんBinaryen自体と文書不足のせいだと思う。Wasmのテキストスニペットを書くのは楽しかったのがせめてもの救いだ jasmine wasmコンパイラ

    • Binaryenは昔のWasmがASTだった頃からのレガシーを多く抱えている。新しい機能は既存モデルに合わせにくい。私たちのコンパイラでは抽象Wasm表現用のデータ構造を別途定義して使い、コンパイルのデフォルトでは.wasm、デバッグ時には.watとしてそれぞれ出力する。かなり直感的なので、命令セット自体は悪くないと思う Scala.js wasm backend

    • TypeScriptでBinaryenを使ってみて同じようにもどかしさを感じた。Rustベースのwasm-toolsに乗り換えたらずっと良い体験だった

    • 具体的にどの部分が大変だったのか気になる。validation errorが本当に厄介なことがあるので、Wizardにも--trace-validationオプションを入れてある。検証過程を見やすく可視化してくれる

    • binaryen.jsの文書やバインディングが実際かなり不足しているのは事実だ。今はcore Binaryenの最適化改善に注力しているので、JS/TS側の進展は遅い。それでも誰かがJS/TSバインディングの改善に時間を割いてくれれば、みんなにとって良いことだと思う

    • 最初から純粋なアセンブリコードを作るほうが簡単だと感じることもある。多くの資料がRustツールに集中しているが、手書きする経験も重要だ。compilerとassemblyは別物であり、Wasmに関心を持つのはコンパイラ開発者だけではない、という視点も必要だ

  • WASMには今でも期待している。今回のリリースは素晴らしく見える。envoyでトラフィックの多いWASMプラグインを動かしているし、zellijのようなターミナルアプリ向けプラグインにもWASMを使っている。小さなサイドプロジェクトではrust leptosベースのwasm Webアプリも運用中だ。正直、3つのうち2つは技術的に最適な選択ではないかもしれないが、この流れは今後もうまく続いていきそうだ。みんなお疲れさま

  • シンプルなのが一番だ。私の願いは、Go structをもっと簡単かつ高速に受け渡しする方法だ。go structをランタイムに入れたり取り出したりするときにコードがこじれず、継ぎはぎの解決策を使わずに済んでほしい。複数言語で使える汎用的な解決策でもいいし、現実的な制約が付くのも構わない。私にとってはgoが一番重要だ

    • その意見には共感する。そしてGCのない言語でも、現実にはそれほど良くならない。実際、wasm上のGC付きランタイムのほうがむしろひどいことが多い。これまで書いたJavaScriptの中で最悪の体験は手動のポインタ整理だった。C++ならスコープを抜ければデストラクタが処理してくれるが、wasmやjsでは全部自分で管理しなければならず、JNIをやっていた頃のほうがまだましだった（goも含む）。しかも苦労してようやくstructひとつ渡せても、呼び出しごとのオーバーヘッドが大きいので、結局はもっと大きな単位にまとめて渡すようになる。私もwasmはパイプラインさえまともになってくれればと思っているが、今までは厳しかった

    • ネイティブコードなら解決策は同じだ。言語間で標準構造（C structなど）に合わせるか、serialize/deserialzieするかだ。複数ランタイムを混在させて使うとき、言語側が直接サポートしていないと本当に面倒な状況になる。なぜこれが問題なのかは明白だ

    • 何を望んでいるのか正確には分からないが、WASIの土台になっているcomponent modelが役立つかもしれない。このモデルでは各モジュールが自前でデータをメモリにマッピングする方法を決められ（将来的にはGC heapまで）、構造体型のようなものもインターフェースとして定義でき、コンパイラがglueコードを自動生成してくれる

    • これはWASM仕様ではなく、ライブラリの領域の話だと思う。内部的にこうしたコードジェネレータをうまく使った経験がある

  • OpenMP対応に期待している。実験的にSolvespaceのWebビルドを動かしていて、OpenMPがサポートされれば大きく改善しそうだ online solvespace demo。ブラウザで動くオープンソースCADだ

    • Solvespaceは本当に素晴らしいツールだと思う。以前YouTubeチュートリアルを見ながら分割キーボードのケースを設計し、CNCで作ったことがある。素早く成果を出せた。メンテナンスしてくれてありがとう

    • これまで見たWASMベースのWeb UIの中で最高だと思う。デスクトップビルドをEmscriptenで回すとき、最も難しかった点は何だったのか気になる

  • まだ言及されていない話なので書いておく。multiple-memories機能がWebGPUリソースのマッピング時に重複コピーを避けるために使えるのか気になる。今はArrayBufferにマップされたものがあるので、WASMではJS経由でコピーしなければならず性能的に不利だ。複数のWASMメモリとClang/LLVMのaddress space機能が解決策になりそうだが、実際にそこまで単純なのかはよく分からない

    • multi-memory toolchain対応の議論はあるが、LLVMで複数アドレス空間を活用した実装が実際にできているのかは分からない

    • これを見ていると昔のsegmented memoryやfar-pointersを思い出す。最近Gameboyのゲームを書いているので、メモリマッピングが「楽しさ」の一部なのは分かるが、制約のない環境でこれを繰り返すのはちょっと嫌だ。DOS/Win16時代にfar pointersが葬られたのには相応の理由があった