Wasm threading/shared memory support

[dschuff]

We need toolchain support for wasm's upcoming support of threads/atomics/shared linear memory. The proposal repo is located at https://github.com/WebAssembly/threads (the important files are https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md and https://github.com/WebAssembly/threads/blob/master/proposals/threads/Globals.md)

I've already started working on this (#1069, #1077, #1082, #1083), but probably should have created this tracking issue first.

This requires several types of support in Binaryen, which we can track the state of here:

• IR for shared memories, and new instructions
  • Shared memories (Add shared memories #1069)
  • Atomic instructions (atomic loads/stores, atomic RMW, cmpxchg, wait/wake) (Add IR, parsing and binary support for AtomicRMW instructions from wasm threads proposal #1082, Add atomic loads and stores #1077, Add IR, parsing, printing, and binary for atomic cmpxchg #1083)
  • Import/export of mutable globals (WIP: Support for mutable global imports/exports #1644 Add support for a mutable globals as a Feature #1785)
  • Sign-extension operators (Add support for sign-extension operators from threading proposal #1167)
• Text and binary encoding for shared memories and new instructions (currently everything that there is IR support for)
• Validation support for new IR (Refactor validation failure and printing, validate atomic alignment #1090, Validation for AtomicRMW and cmpxchg #1092)
• Optimizer support for new IR (Optimizer support for atomic instructions #1094)
• asm2wasm support
• [ ] s2wasm support (or s2wasm's replacement)
• Interpreter support for new IR

[dschuff]

Currently there are no complete implementations of wasm threads in any JS VMs that I know of, but work has started in V8 and probably others too.

My highest-priority goal is to support end-to-end compilation with emscripten ASAP to test with the VMs. But of course if we end up getting things working before the VMs are ready then we can still probably do some testing with the interpreter. And of course this also requires some work on the emscripten side. Fortunately there's already some pthreads support for asm.js there, so hopefully it won't be too huge.

[lars-t-hansen]

Currently there are no complete implementations of wasm threads in any JS VMs that I know of, but work has started in V8 and probably others too.

Work is going on in SpiderMonkey but given current workloads and summer vacation schedules we're not expecting to be done until late Q3 (and that's not a commitment, just a well-educated guess).

[Lachrista]

@dschuff
I use -s USE_PTHREADS=1 -s WASM=1 to compile a wasm.but ,When I use the wasm file in firefox and Google, it's error reporting.
"Uncaught TypeError: [object Uint32Array] is not an integer shared typed array.
at Atomics.store ()
at Object.initMainThreadBlock "
I don't understand why this is, because it can be used normally in asm. Js.
This problem is very upsetting to me. I don't know how to solve it.

[dschuff]

Wasm support for threads depends on the webassembly threads proposal (tracked in https://github.com/WebAssembly/threads) and is not yet shipped by default in browsers. This page describes how to turn wasm thread support on in Chrome and Firefox. Although since then, both browsers have also turned SharedArrayBuffer off by default too, so you need to turn that on as well. For chrome you can change the command line to include --enable-features='WebAssembly SharedArrayBuffer'

[Lachrista]

I don't think that's the reason.
Because I have already opened the corresponding configuration in Google, but it will still be wrong.
chrome://flags/ ,I've already set up
(1)shared-array-buffer
(2)All about webassembly
now ,Has been an error
"Uncaught TypeError: [object Uint32Array] is not an integer shared typed array.
at Atomics.store ()
at Object.initMainThreadBlock "
I don't know how to solve this problem.

[jayphelps]

Mutable globals now supported by @sbc100 🎉 #1785

[dschuff]

Thanks @jayphelps (and @sbc100)! Since we've implemented all the features I'll just close this issue, and any new work will just be bugfixes and enhancements.