1334941 - Support asm.js validation on SharedArrayBuffer heap

Status: UNCONFIRMED

(Core :: JavaScript Engine, defect, P3)

Description

[Bobby Powers]

Attachment: 0001-SAB-asm.js-support.patch

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36

Steps to reproduce:

I have a set of asm.js programs here: https://browsix.org/latex-demo-sync/ (currently only runs in Dev + Nightly editions of Firefox, as it depends on DataViews on SharedArrayBuffers).  We run C programs in Web Workers, and perform "system calls" between workers and the main JS thread with a combination of message passing (to initiate a system call handler on the main JS thread) and an Atomics.wait() on a prearranged address in the SharedArrayBuffer we use as the C heap.

This works (super exciting!), but currently fails asm.js validation.




Actual results:

Validation fails with the messages:

TypeError: asm.js link error: unshared views can only be constructed onto ArrayBuffer  
TypeError: asm.js type error: Disabled by 'asmjs' runtime option



Expected results:

Currently in the engines SharedArrayBuffers can only be used as the backing heap in "wasm test mode".  I think this should be relaxed.

When I modify Firefox to enable SharedArrayBuffer heaps to pass validation, performance improves by over 3x!

I've attached a patch, and if this approach sounds reasonable to people, I'm happy to work to get something like this accepted.

Comment 1

[Bobby Powers]

Additional info:

I'm one of the authors of Browsix, a framework to run C, C++ and Go programs as processes (in Web Workers) in the browser ( https://browsix.org ; https://github.com/plasma-umass/browsix ; paper: https://arxiv.org/abs/1611.07862 ).

This patch improves the runtime of pdflatex from 2.6 seconds to .79 seconds, over a 3x improvement, and patched-Firefox execution time is more than twice as fast as execution in Chrome or Safari!  Its super impressive -- when we're able to pass asm.js validation execution is within 10x of native, and pdflatex performs thousands of Browsix system calls.

Comment 2

[Luke Wagner [:luke]]

With wasm close to shipping, the goal is for asm.js users to transition to wasm (which should mostly be as easy as recompiling with an updated Emscripten) and for us to eventually remove the special asm.js path in the engine (which reduces complexity, attack surface, bugs, etc).  While wasm v.1 doesn't have shared memory, I think we'll be able to add this pretty shortly after wasm v.1 is shipping by simply allowing Memory objects to be shared between workers and exposing the already-defined-in-JS Atomic ops to wasm.  Thus, I'm reticent to add this asm.js-only capability for a short duration when what we really want is for people to migrate to wasm.

Additional reasons to hold back atomics-in-asm.js include:
 - asm.js currently doesn't have a good way to share code between workers, leading to num-threads copies of code
 - atomics-in-asm.js have slightly different corner-case behavior than both normal asm.js loads/stores and atomics-in-wasm, which adds complexity and a chance for bugs