1965217 - Allow SharedArrayBuffer in WebAssembly compile methods

Status: RESOLVED FIXED

(Core :: JavaScript: WebAssembly, defect, P3)

Description

[Fra]

Attachment: testCase.tar.gz

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

Steps to reproduce:

Tried to run the WebAssembly.compile() with an argument of typeTypedArray that comes from a SharedBufferArray

Actual results:

The function failed, error Type: failed to compile in wasm: first argument must be an ArrayBuffer or typed array object

Expected results:

In previous versions (e.g. 137) the function WebAssembly.compile() should have accepted the TypedArray, even from a SharedBuffer, is this behaviour intended or is something that needs to be addressed and fixed?

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript: WebAssembly' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[André Bargull [:anba]]

Regression from bug 1931407, but likely intentional when reading the commit message from https://phabricator.services.mozilla.com/D235240.

Comment 3

[Fra]

I see, but according to what said in bug 1931407 Chrome indeed blocks and argument of type SAB, but does support TypedArrays backed by SAB (and AB of course), while Firefox doesn't accept such TypedArray; why is that?

Comment 4

[Ryan Hunt [:rhunt]]

That sounds like a Chrome bug to me. The Wasm JS-API spec requires BufferSource [1] which is either an array buffer or a view of an ArrayBuffer.

What use case do you have for passing a typed array view backed by shared memory to the compile methods?

[1] https://webassembly.github.io/spec/js-api/index.html#webassembly-namespace
[2] https://webidl.spec.whatwg.org/#BufferSource

Comment 5

[Fra]

The very same I linked in my first message

Comment 6

[Fra]

Currently, the use case refers to our website: https://webvm.io/

Although a fix has been implemented to address the issue, it's worth noting that this fix comes at a performance cost: since a non-shared copy + its view of the SAB array is created, that leads to more overhead to the engine.

The originally reported problem is documented in this GitHub issue

Comment 7

[Ryan Hunt [:rhunt]]

Thanks for that context. I think this is something that should be taken up in the Wasm standards group, as our behavior is spec compliant now. Chrome's behavior also seems odd to me. Why allow views of shared buffers, but not allow shared buffers? I filed an issue in the spec to discuss this there [1].

[1] https://github.com/WebAssembly/spec/issues/1907

Comment 8

[Ryan Hunt [:rhunt]]

It appears that we'll resolve the issue in favor of allowing SAB in the compile methods.

Comment 9

[Ryan Hunt [:rhunt]]

Attachment: Bug 1965217 - wasm: [AllowShared] and [AllowResizable] for buffer source. r?bvisness

If a buffer is shared, we need to make a copy of it. Otherwise we
can just reference it directly.

1. Update BytecodeBufferOrSource to use variant and actually
   hold the BytecodeBuffer directly. Previously it just pointed
   at it.
2. Add GetBytecodeBufferOrSourceIfUnshared which will grab a reference
   to the source if it's unshared, otherwise it will make a copy of
   the buffer.
3. Use this new method for sync compile/instantiate/validate.
4. Pass 'allowShared' to IsBufferSource to allow SAB.

Comment 10

[Ben Visness [:bvisness]]

Looks like this is probably good to go, since the upstream spec change has been merged: https://github.com/WebAssembly/spec/pull/2084

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/242515433224
https://hg.mozilla.org/integration/autoland/rev/169307955098
wasm: [AllowShared] and [AllowResizable] for buffer source. r=bvisness

Comment 12

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/169307955098