WebAssembly Web API

1. はじめに

2. ストリーミングモジュールのコンパイルとインスタンス化

[Exposed=(Window,Worker)]
partial namespace WebAssembly {
  Promise<Module> compileStreaming(Promise<Response> source, optional WebAssemblyCompileOptions options = {});
  Promise<WebAssemblyInstantiatedSource> instantiateStreaming(
      Promise<Response> source, optional object importObject, optional WebAssemblyCompileOptions options = {});
};

3. シリアライズ

WebユーザーエージェントはModule インターフェースに [Serializable] 拡張属性を追加しなければなりません。

シリアライズ手順は、value, serialized, forStorageを受けて次のようにします：

1. forStorageがtrueなら「DataCloneError」DOMException をスローする。

2. serialized.[[Bytes]] に サブシリアライズ value.[[Bytes]] をセットする。

3. serialized.[[AgentCluster]] に 現在のRealmの agent clusterをセットする。

デシリアライズ手順はserialized、value、targetRealmを受けて：

1. bytes をサブデシリアライズ serialized.[[Bytes]] とする。

2. value.[[Bytes]] を bytes とする。

3. もし targetRealm の agent cluster が serialized.[[AgentCluster]] と異なれば、「DataCloneError」DOMException をスローする。

4. WebAssemblyモジュールをコンパイル bytes から行い、value.[[Module]]にその結果をセットする。

エンジンは構造化シリアライズ時に内部コンパイル済みコードの共有や再利用を試みるべきですが、CPUアップグレードやブラウザ更新などの場合は再コンパイルが必要なこともあります。

注：構造化シリアライズの意味論は、Module がコンパイルされたバイナリソースをシリアライズし、デシリアライズしてターゲットrealmで再コンパイルするのと同等です。 上記のエンジン最適化により、構造化シリアライズはコンパイル済みコードのキャッシュやウィンドウ・ワーカー間でのコード共有を開発者が明示的に制御可能としています。

4. 開発者向け表示規約

このセクションは規範的でありません。

ブラウザ、JavaScriptエンジン、オフラインツールは、JavaScriptの成果物や言語構成要素を表現する共通の方法を持っています。たとえば、JavaScriptソースの位置はスタックトレースやエラーメッセージで表示され、テキストファイル中の行・列番号などは10進表記が使われます。関数名や変数名はソースからそのまま持ってきます。よって（たとえ実装依存のスタックトレース文字列の詳細な形式が異なっても）場所はわかりやすく、ブラウザ間で共通です。

WebAssembly構成要素に対しても同様の共通表記を提供するために、以下の規約を採用します。

WebAssemblyの場所（ロケーション）はバイナリ中の特定命令への参照で、ブラウザやエンジンが同様の文脈（JavaScriptのソース位置表示など）で表示できます。形式は以下です：

${url}:wasm-function[${funcIndex}]:${pcOffset}

各要素は：

• ${url} は該当する場合はモジュールに関連付けられたURL（注参照）

• ${funcIndex} はモジュール内の関数インデックス

• ${pcOffset} は、命令の先頭バイトまでのバイナリ内オフセットで、16進小文字・0xプリフィックス付で表示

注記：

• URLのフィールドは文脈に応じて解釈されます。ブラウザでレスポンスベースのインスタンス化APIを使う場合は対応するURLを用い、ArrayBufferベースの インスタンス化APIならそのAPIコール位置をブラウザが表示します。これはJavaScriptのevalに相当します。ブラウザが foo.js line 10 > eval や eval at bar (foo.js:10:3)のように表示している場合、 foo.js line 10 > WebAssembly.instantiateやWebAssembly.instantiate at bar (foo.js:10:3)のように使っても良いです。オフラインツールならファイル名にします。

• モジュールオフセットを16進で表示するのはobjdumpなどのネイティブツールの慣例に合わせたもので、JavaScriptの行番号と区別しやすくする意図もあります。他の番号は10進で表記されます。

Exported Function インスタンスの"name"プロパティはJS APIで定義されていますが、呼び出し階層（コールスタック）やスタックトレースなど他の文脈でも合成された関数名も表示されます。 WebAssemblyモジュールにnameセクション がある場合、関数名の合成は以下の通りに行います：

• 関数名サブセクションがあれば、表示名は${module_name}.${function_name}またはモジュール名が無ければ${function_name}とします。

• それ以外の場合、出力は文脈依存にできます：

  • 関数名がスタックトレース位置と一緒に表示される場合、モジュール名（あれば）または空文字で良い（関数インデックスはすでに場所で示されています）。

  • それ以外は${module_name}.wasm-function[${funcIndex}]やwasm-function[${funcIndex}]のように関数インデックスが分かる形式にします。

本仕様はスタックフレーム表現などの文字列全体の書式を規定しません；これにより、既存のJavaScript用実装（およびそれを参照する既存コード）を変えずに、WebAssemblyフレームだけをJavaScriptと一貫した形式で出力できます。

5. メディアタイプ登録

メディアタイプapplication/wasmはIANAメディアタイプデータベース[IANA-MEDIA-TYPES]に登録されており、以下の登録テンプレートが存在します：

application/wasm

タイプ名:

application

サブタイプ名:

wasm

必須パラメーター:

なし

オプションパラメーター:

なし

エンコーディングの考慮事項:

バイナリ

セキュリティ上の考慮点:

WebAssemblyは標準化され、安全かつ移植可能な低レベルコード形式です。WebAssemblyコードの実行にあたるセキュリティ上の考慮点は https://www.w3.org/TR/wasm-core/#security-considerations に記載されています。

WebAssemblyフォーマット自体は完全性やプライバシー保護を持ちません。必要な場合は外部的に保護（例: HTTPS使用）してください。

相互運用性の考慮点:

WebAssemblyコア適合性参照
https://www.w3.org/TR/wasm-core/#conformance

公開仕様:

https://www.w3.org/TR/wasm-core-1/ https://www.w3.org/TR/wasm-js-api-1/ https://www.w3.org/TR/wasm-web-api-1/

用途:

application/wasmメディアタイプは、WebAssemblyファイルをHTTP経由で配信してブラウザで実行する場合などを想定しています。また、安全性と移植性を活用したWebAssemblyランタイムでも利用されています。

フラグメント識別子に関する考慮点:

なし

使用上の制限:

なし

暫定登録:

N/A

追加情報:

このタイプの非推奨エイリアス名:

なし

マジックナンバー:

0x00 0x61 0x73 0x6D

ファイル拡張子:

.wasm

Macintosh ファイルタイプコード:

なし

オブジェクト識別子またはOID:

なし

意図される用途:

共通

その他情報・コメント:

共通

連絡先:

担当者名:

Eric Prud’hommeaux

メールアドレス:

eric@w3.org

著者／変更管理者:

W3C

6. セキュリティおよびプライバシーに関する考慮事項

このセクションは規範的でありません。

WebAssembly は追加のプログラム実行機構であり、JavaScript が実行できる場所ならどこでも実行できます。 したがって、脅威モデルは基本的に JavaScript コードと同じであり、配信上の考慮事項（例：WebAssembly コードもネットワーク攻撃者から守るべき）、ポリシー上の考慮事項（例：同一生成元ポリシーや Content Security Policy によるロード/実行制限）も同様です。

7. 変更履歴

このセクションは規範的でありません。

WebAssembly仕様 1.0 のオリジナルリリース以降、拡張のための多くの提案が統合されてきました。 以下のセクションではこれまでの変更点の概要を示します。

7.1. リリース2.0

メディアタイプ登録完了