Intent to Ship: WebAssembly

[Ben L. Titzer]

Contact emails

tit...@google.com, bradn...@google.com, sethth...@google.com

Spec

https://github.com/WebAssembly/design/

Summary

WebAssembly provides a portable binary code format that serves as a low-level compilation target for native languages. It offers high performance and interoperability with JavaScript and WebAPIs. It is implemented within the JavaScript engine of the browser (V8 in the case of Chrome).

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/forum/#!topic/v8-users/PInzACvS5I4

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/Dogpn1hpnhw

Link to Origin Trial feedback summary

N/A

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo link

http://webassembly.org/demo/

Debuggability

WebAssembly has some special support for debugging in DevTools. In particular, DevTools now has support to view WebAssembly stack frames and the disassembled bytecode for WebAssembly stack frames. Breakpoints and stepping of individual instructions are currently under development and nearly complete.

Interoperability and Compatibility Risk

WebAssembly is a new feature, so it does not have a backward compatibility risk (yet).

It has been developed through an open process in the W3C in which Google, Mozilla, Microsoft, and Apple have collaborated on the design and specification.

Both Mozilla and Microsoft have complete or nearly complete implementations following the shared spec, while Apple is currently developing an implementation.

According to our shared roadmap (http://webassembly.org/roadmap/), other browsers are working towards shipping WebAssembly in the same time frame.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=575167

Entry on the feature dashboard

https://www.chromestatus.com/features/5453022515691520

[Jochen Eisinger]

Can you summarize which APIs / features you want to ship here? Does this include the ability to postMessage wasm binaries?

[Ben L. Titzer]

The JavaScript API that is exposed to WebAssembly is described here:

https://github.com/WebAssembly/design/blob/master/JS.md

Short summary:

the top-level functions:

WebAssembly

WebAssembly.Module

WebAssembly.Instance

WebAssembly.Table

WebAssembly.Memory

WebAssembly.RuntimeError

WebAssembly.CompileError

WebAssembly.LinkError

[Jochen Eisinger]

ok, shipping WebAssembly.* lgtm1

[Rick Byers]

I see that the spec is currently just a reference implementation for an interpreter.  I like this approach personally but I'm sure it'll raise some eyebrows (the typical concern I've heard is that a reference implementation often doesn't explain why something is a certain way, but I'd argue the same is often true for specs).  Have the other vendors said anything publicly about their comfort level with us shipping now (potentially locking in some design decisions)?

What can you say about the test suite - do you feel it's reasonably complete in terms of mitigating the most common sources of interop risk?  Are we running this test suite in the blink infrastructure anywhere?  Can you point to the results for our current implementation?

Thanks,

 Rick

[Ben L. Titzer]

On Tue, Jan 10, 2017 at 7:24 PM, Rick Byers <rby...@chromium.org> wrote:

I see that the spec is currently just a reference implementation for an interpreter.  I like this approach personally but I'm sure it'll raise some eyebrows (the typical concern I've heard is that a reference implementation often doesn't explain why something is a certain way, but I'd argue the same is often true for specs).  Have the other vendors said anything publicly about their comfort level with us shipping now (potentially locking in some design decisions)?

rossberg@ is already starting work on a formal spec that will include descriptions of all the opcodes in both spec-ese English and a formal treatment with type rules.

We discussed this today in our cross-vendor meeting and there were no vetoes. Mozilla's current state is that they have WebAssembly turned on in nightly (but not Beta), and they plan to flip their flag on in Beta coupled with the last version change around the end of February.

The reason for flipping the flag now (effectively shipping) is that we'll get canary coverage of the on-by-default coverage, with only one minor binary-format-version-supported flag flip around the same time as Mozilla.

Microsoft cannot give an exact date for shipping, as Edge is tied to the next Windows release.

Apple is working on an implementation but doesn't make statements about when/if they will ship.

 

What can you say about the test suite - do you feel it's reasonably complete in terms of mitigating the most common sources of interop risk?  Are we running this test suite in the blink infrastructure anywhere?  Can you point to the results for our current implementation?

We pass almost all of this test suite, and of course we have our own internal test suite. We also started running tests from Mozilla's internal repos and we are working with them to develop a common push-button compliance suite that can run in-browser that will be essentially a union of the spec tests and all of our individual tests.

Our internal tests run on the v8 waterfall, and there is an integration dashboard for end-to-end tests (triggered by LLVM builds): https://build.chromium.org/p/client.wasm.llvm/console

[Chris Harrelson]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[kai zhu]

wootwoot!  we're one step closer to having websites being able to load sqlite3 as a binary asset (something that has sorely hindered advancement in frontend-development).  also look forward to the day .wasm will replace java binaries : )

[Rick Byers]

I talked with some Mozilla folks a little and looked a little into the binary versioning implications (since this is apparently not the "stable" binary version).  But the risk seems OK so since the larger WebAsm community is OK with us shipping a little aggressively, and this work is really high impact and urgent, I am too.

LGTM3

Sorry for the delay (I assume if this is just flipping the bit, merging that to the M57 branch is reasonable).