Search code examples
google-chromegoogle-nativeclientwebassembly

Future of native-client after WebAssembly Post-MVP

I am sure after WebAssembly Post-MVP, asm.js will be deprecated. Even now, a few existing asm.js projects already start to use WebAssembly. JS engine (V8) also starts to comiple asm.js to WebAssembly, so even if old projects never migrate, end-users will still get partial advantages from WebAssembly.

My question is, what about native-client then? It is not implemented in JS engine so that can be a problem. Native-client seems to be deprecated even now. Will native-client be completely removed from Chrome in foreseeable future? I would love to see some reduction in binary size of Chrome.

Side questions:

  • After thread/gc/simd/exception are included in WebAssembly, is there still something native-client has but missing in WebAssembly (blocking migration)?
  • It took WebAssembly about 2 years just to reach MVP, what is the expected time for any one of the Post-MVP to get finalized?
  • It seems like WebAssembly group is tackling multiple Post-MVP features at once instead of one by one, won't that make it slower to finalize one of them?
Solution

  • Answering the side-questions only, because I no longer work on Native Client. Google's plans are its own to speak for, so I'll make this a wiki.

    Update as of 2017/05/20 NaCl isn't in glibc. This was the original libc which was supported, and took quite a while to clean up and upstream. It was only ever supported by NaCl's GCC toolchain. There's still support for musl libc, which works with the more up-to-date LLVM-based NaCl and PNaCl toolchain.

    Update as of 2017/05/30 the Chromium team announced the fate of PNaCl and tentative roadmap of WebAssembly features.

    Here are some Native Client features which you haven't mentioned:

    • Out-of-process, which many consider a bug because it forces asynchronous communication. It allows guaranteed address space, which with 64-bit isn't much of an upside, and was critical to Native Client's double-sandbox design. WebAssembly doesn't have processes yet.
    • Has blocking to and from the JavaScript event loop, through postMessageAndAwaitResponse. Also seen as a bug by many.
    • Has many APIs through Pepper. Many mirror the web platform's APIs.
    • Can do memory protection through mprotect (though execute pages are limited).
    • POSIX signals can be handled.
    • Supports computed goto and other irreducible control flow.
    • Has some Just-in-Time code patching support.
    • Supports weaker than seq_cst atomics.
    • Has support for inline assembly, as long as it follows the NaCl validation rules.

    Not all of these are in Portable Native Client, though. There's official documentation of differences.

    There's no timeline for any of the post-MVP WebAssembly features. We don't want to rush anything, but we want to deliver one the most useful things first. It's a community group, so priorities are really driven by whoever gets involved. Implementations won't be able to tackle features all at once, but exploration parallelizes well.