Tuesday, March 15, 2016

Experimental support for WebAssembly in V8

For a comprehensive overview of WebAssembly and a roadmap for future community collaboration, see A WebAssembly Milestone on the Mozilla Hacks blog.

Since June 2015, collaborators from Google, Mozilla, Microsoft, Apple and the W3C WebAssembly Community Group have been hard at work designing, specifying, and implementing [1][2][3][4] WebAssembly, a new runtime and compilation target for the web. WebAssembly is a low-level, portable bytecode that is designed to be encoded in a compact binary format and executed at near-native speed in a memory-safe sandbox. As an evolution of existing technologies, WebAssembly is tightly integrated with the web platform, as well as faster to download over the network and faster to instantiate than asm.js, a low-level subset of JavaScript.

Starting today, experimental support for WebAssembly is available in V8 and Chromium behind a flag. To try it out in V8, run d8 version 5.1.117 or greater from the command line with the --expose_wasm flag or turn on the Experimental WebAssembly feature under chrome://flags#enable-webassembly in Chrome Canary 51.0.2677.0 or greater. After restarting the browser, a new Wasm object will be available from the JavaScript context which exposes an API that can instantiate and run WebAssembly modules. Thanks to the efforts of collaborators at Mozilla and Microsoft, two compatible implementations of WebAssembly are also running behind a flag in Firefox Nightly and in an internal build of Microsoft Edge (demonstrated in a video screencapture).

The WebAssembly project website has a demo showcasing the runtime’s usage in a 3D game. In browsers that support WebAssembly, the demo page will load and instantiate a wasm module that uses WebGL and other web platform APIs to render an interactive game. In other browsers, the demo page falls back to an asm.js version of the same game.

https://webassembly.github.io/demo/

Under the hood, the WebAssembly implementation in V8 is designed to reuse much of the existing JavaScript virtual machine infrastructure, specifically the TurboFan compiler. A specialized WebAssembly decoder validates modules by checking types, local variable indices, function references, return values, and control flow structure in a single pass. The decoder produces a TurboFan graph which is processed by various optimization passes and finally turned into machine code by the same backend which generates machine code for optimized JavaScript and asm.js. In the next few months, the team will concentrate on improving the startup time of the V8 implementation through compiler tuning, parallelism, and compilation policy improvements.

Two upcoming changes will also significantly improve the developer experience. A standard textual representation of WebAssembly will enable developers to view the source of a WebAssembly binary like any other web script or resource. In addition, the current placeholder Wasm object will be redesigned to provide a more powerful, idiomatic set of methods and properties to instantiate and introspect WebAssembly modules from JavaScript.

The V8 / WebAssembly team looks forward to continued collaboration with other browser vendors and the greater community as we work towards a stable release of the runtime. We’re also planning future WebAssembly features (including multi-threading, dynamic linking, and GC / first-class DOM integration) and continuing the development of toolchains for compiling C, C++, and other languages via the WebAssembly LLVM backend and Emscripten. Check back for more updates as the design and implementation process continues.

Posted by Seth Thompson, WebAssembly Wrangler

15 comments:

  1. Faster javascript is always welcome.
    I see a danger where websites will push very large or very resourse consuming webassembly to a browser and the end user is framed.
    Control of what happens in a users' browser is highly desirable, especially if you can visit a website and have a risk to get flooded with resource consuming webassembly. This risk is already present with plain javascript but gets bigger with webassembly.

    ReplyDelete
    Replies
    1. I don't see, how is the risk of consuming resources bigger with WebAssembly than with Javascript.

      If you find a "bad" website (make your own definition of bad), you simply don't visit it next time. That is how the web works.

      Delete
  2. Can't wait to see what the community does with this new powerful feature of the web :-)

    ReplyDelete
  3. I just posted this Stackoverflow question about Webassembly/Turbofan:

    http://stackoverflow.com/questions/36042935/is-there-a-way-of-providing-asm-js-or-webassembly-code-to-v8-turbofan

    ReplyDelete
  4. Replies
    1. Its in Chrome Canary: https://www.google.com/chrome/browser/canary.html
      You will need to turn it turn on the Experimental WebAssembly feature under chrome://flags#enable-webassembly.

      Delete
  5. Do you have any estimate of when it will be available in a standard Chrome without a flag?

    ReplyDelete
  6. I'm so excited, this is great news!

    ReplyDelete
  7. This comment has been removed by the author.

    ReplyDelete
  8. how can i find a doc to explain how to transform a javascript code into a binary web assembly code?
    have you a link?

    ReplyDelete
    Replies
    1. All the relevant information should be available on https://webassembly.github.io/. Keep in mind that transforming typical JavaScript to WASM is not the common use case. WASM is more about running native code on the web.

      Delete