This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This document is a First Public Working Draft.
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
GitHub Issues are preferred for discussion of this specification. All issues and comments are archived.
This document was produced by the WebAssembly Working Group.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 February 2018 W3C Process Document.
Table of ContentsThis document builds off of the WebAssembly specification [WEBASSEMBLY] and the WebAssembly JavaScript embedding [WASMJS].
1. Streaming Module Compilation and Instantiationpartial namespace WebAssembly {
Promise<Module> compileStreaming(Promise<Response> source);
Promise<WebAssemblyInstantiatedSource> instantiateStreaming(
Promise<Response> source, optional object importObject);
};
To
compile a potential WebAssembly responsewith a promise of a
Response source
, perform the following steps:
Note: This algorithm accepts a Response object, or a promise for one, and compiles and instantiates the resulting bytes of the response. This compilation can be performed in the background and in a streaming manner. If the Response is not CORS-same-origin, does not represent an ok status, or does not match the `application/wasm` MIME type, the returned promise will be rejected with a TypeError; if compilation or instantiation fails, the returned promise will be rejected with a CompileError or other relevant error type, depending on the cause of failure.
Let returnValue be a new promise
Upon fulfillment of source with value unwrappedSource:
Let response be unwrappedSource’s response.
Let mimeType be the result of extracting a MIME type from response’s header list.
If mimeType is not `application/wasm`, reject returnValue with a TypeError and abort these substeps.
Note: extra parameters are not allowed, including the empty `application/wasm;`.
If response is not CORS-same-origin, reject returnValue with a TypeError and abort these substeps.
If response’s status is not an ok status, reject returnValue with a TypeError and abort these substeps.
consume response’s body as an ArrayBuffer, and let bodyPromise be the result.
Note: Although it is specified here that the response is consumed entirely before compilation proceeds, that is purely for ease of specification; implementations are likely to instead perform processing in a streaming fashion. The different is unobservable, and thus the simpler model is specified.
Upon fulfillment of bodyPromise with value bodyArrayBuffer:
Asynchronously compile the WebAssembly module bodyArrayBuffer with returnValue using the networking task source.
Upon rejection of bodyPromise with reason reason:
Reject returnValue with reason.
Upon rejection of source with reason reason:
Reject returnValue with reason.
Return returnValue.
Browsers, JavaScript engines, and offline tools have common ways of referring to JavaScript artifacts and language constructs. For example, locations in JavaScript source code are printed in stack traces or error messages, and are represented naturally as decimal-format lines and columns in text files. Names of functions and variables are taken directly from the sources. Therefore (for example) even though the exact format of implementation-dependent stack trace strings does not always match, the locations are easily understandable and the same across browsers.
To achive the same goal of a common representations for WebAssembly constructs, the following conventions are adopted.
A WebAssembly location is a reference to a particular instruction in the binary, and may be displayed by a browser or engine in similar contexts as JavaScript source locations. It has the following format:
${url}:wasm-function[${funcIndex}]:${pcOffset}
Where
${url} is the URL associated with the module, if applicable (see notes).
${funcIndex} is the function index relative to the module.
${pcOffset} is the offset in the module binary of the first byte of the instruction, printed in hexadecimal with lower-case digits, with a leading 0x prefix.
Notes:
The URL field may be interpreted differently depending on the context. When the response-based instantiation API is used in a browser, the associated URL should be used; or when the ArrayBuffer-based instantiation API is used, the browser should represent the location of the API call. This kind of instantiation is analagous to executing JavaScript using eval; therefore if the browser has an existing method to represent the location of the eval call it can use a similar one for WebAssembly.instantiate. For example if the browser uses foo.js line 10 > eval or eval at bar (foo.js:10:3) for eval, it could use foo.js line 10 > WebAssembly.instantiate or WebAssembly.instantiate at bar (foo.js:10:3), respectively. Offline tools may use a filename instead.
Using hexadecimal for module offsets matches common conventions in native tools such as objdump (where addresses are printed in hex) and makes them visually distinct from JavaScript line numbers. Other numbers are represented in decimal.
While the "name" property of an Exported Function instance is specified by the [[WASMJS|JS API]], synthesized function names are also displayed in other contexts like call stacks in debuggers and string representations of stack traces. If a WebAssembly module contains a [="name" section=], these names should be used to synthesize a function name as follows:
If a function name subsection is present, the displayed name should be ${module_name}.${function_name} or ${function_name}, depending on whether the module name is present.
Otherwise, the output can be context-dependent:
If the function name is shown alongside its location in a stack trace, then just the module name (if present) or an empty string can be used (because the function index is already in the location).
Otherwise, ${module_name}.wasm-function[${funcIndex}] or wasm-function[${funcIndex}] should be used to convey the function index.
Note that this document does not specify the full format of strings such as stack frame representations; this allows engines to continue using their existing formats for JavaScript (which existing code may already be depending on) while still printing WebAssembly frames in a format consistent with JavaScript.
Conformance Document conventionsConformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:
This is an example of an informative example.
Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:
Note, this is an informative note.
Index Terms defined by this specificationpartial namespace WebAssembly {
Promise<Module> compileStreaming(Promise<Response> source);
Promise<WebAssemblyInstantiatedSource> instantiateStreaming(
Promise<Response> source, optional object importObject);
};
#dom-webassembly-compilestreamingReferenced in:
#dom-webassembly-instantiatestreamingReferenced in:
#compile-a-potential-webassembly-responseReferenced in:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3