Intent to Ship: SharedArrayBuffer

[Brad]

Contact emails

bi...@chromium.org, asee...@chromium.org, bradn...@chromium.org, sethth...@chromium.org

Spec

Merged into ECMAscript spec:

https://tc39.github.io/ecma262/

(Sections referencing Atomics / SharedArrayBuffer)

Last separate draft:

https://tc39.github.io/ecmascript_sharedmem/shmem.html

TAG review submitted here: https://github.com/w3ctag/spec-reviews/issues/165

Summary

Gives JavaScript access to shared memory, atomics, and futex.

Adds a new JavaScript type SharedArrayBuffer mirroring ArrayBuffer, which can be posted to Web Workers without disconnecting the buffer from the sending side.
Re-uses Int8Array etc, to provide views into memory.
Adds a new top level Atomics object, containing atomic and futex operations.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/d-0ibJwCS24

Link to Origin Trial feedback summary

N/A

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo links

https://flagxor.github.io/sab-demo/convolve-multicore/convolve.html

https://browsix.org/latex-demo-sync/

(You must enable under about:flags)

Debuggability

Leverages existing debugging support for Web Workers.

Interoperability and Compatibility Risk

There is a low interoperability risk as implementations exist from all major browsers, and a test suite has been added to the standard ECMAscript test suite test262. The specification has been designed with affordances for efficient implementation on multiple architectures present and future.

Edge: Implemented, plan to ship in a future version

Firefox: Implement, launched in Nightly, expected to ship soon

Safari: Shipped (Safari 10.1)

Web developers: Positive (regularly asked when it will be available)

Security Note

Shipping a web browser involves both exposing new capabilities for developers to build useful applications and protecting users against ways in which those capabilities could be used maliciously. SharedArrayBuffers provide a useful primitive for efficient communication between web workers, and in turn dramatic performance benefits for web applications that rely on synchronizing multi-threaded behavior. Adding communication primitives between threads or workers has the inherent side-effect of exposing a mechanism to manually construct high-resolution timers. Such timers (also exposed via Flash, PNaCl, and some performance.now implementations) are a prerequisite for a class of side-channel attacks that observe cache accesses by measuring the time it takes to perform various computations. Historically, Chrome has significantly reduced the resolution of performance.now and added timing jitter where doing so doesn’t impede otherwise useful web capabilities. However, in practice, the existence of high-resolution timers has not been sufficient to demonstrate general exploits on non-quiescent machines. Moreover, from past experience, real-world attackers tend to attempt to exploit more straightforward, reliable, and powerful attacks than those that high-resolution timers abet. Ultimately, avoiding exposing high-resolution timers indefinitely is unlikely to be a practical long-term solution to preventing observation of information leaks–the real solution to this class of attack vectors is mitigations at the hardware and OS levels and/or mitigations in high-layer designs that avoid information leaks in the first place. The Chrome team believes that SharedArrayBuffers pose many more benefits than risks, and that SABs are not uniquely risky from a security perspective.

Of all the tests for web-exposed behavior, are any not in web-platform-tests? Please explain and link to bugs.

Tests of the feature are included as part of test262, ECMAscript's primary compliance suite:

https://github.com/tc39/test262/tree/master/test/built-ins/SharedArrayBuffer

https://github.com/tc39/test262/tree/master/test/built-ins/Atomics

Chrome's implementation passes 100% of these.

OWP launch tracking bug

https://crbug.com/709179

Entry on the feature dashboard

https://www.chromestatus.com/features/4570991992766464

Implementation Status Note

Note two remaining CLs need to make the branch for M59. These are expected to land shortly.

Limit the feature to WebGL:

https://codereview.chromium.org/2707243006/

Switch all atomics TurboFan ops (needed for edge case behavior on arm):

https://codereview.chromium.org/2799863002/

[Eli Grey]

Does this mean that issue 506723 will also be reverted? The mitigation implemented in issue 506723 becomes toothless once I can use SharedArrayBuffer-based timers such as https://codepen.io/yossioren/pen/LVBNMR.

[Eli Grey]

Oh I just realized that specific example won't work in Chrome after this lands, but it can be modified to work using WebGL from the looks of it.

[Anne van Kesteren]

On Fri, Apr 7, 2017 at 12:38 AM, Brad <bradn...@chromium.org> wrote:
> Spec
>
> Merged into ECMAscript spec:
>
> https://tc39.github.io/ecma262/
>
> (Sections referencing Atomics / SharedArrayBuffer)
>
> Last separate draft:
>
> https://tc39.github.io/ecmascript_sharedmem/shmem.html

Does this mean you won't ship support for serializing and
deserializing these objects (formerly called structured cloning)? (I'm
asking as the standard for those is not quite ready yet and what I've
heard from in-progress implementations is that they're a little
different from how we envision they should work.) Relevant pointers
for that work:

https://github.com/whatwg/html/issues/2260
https://github.com/tc39/ecmascript_sharedmem/issues/144
https://github.com/whatwg/html/pull/2361
https://github.com/w3c/web-platform-tests/issues/5003


--
https://annevankesteren.nl/

[Anne van Kesteren]

On Fri, Apr 7, 2017 at 9:02 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> Does this mean you won't ship support for serializing and
> deserializing these objects (formerly called structured cloning)? (I'm
> asking as the standard for those is not quite ready yet and what I've
> heard from in-progress implementations is that they're a little
> different from how we envision they should work.) Relevant pointers
> for that work:
>
> https://github.com/whatwg/html/issues/2260
> https://github.com/tc39/ecmascript_sharedmem/issues/144
> https://github.com/whatwg/html/pull/2361
> https://github.com/w3c/web-platform-tests/issues/5003

I realized after sending this that the feature is rather useless
without such support, so I hope you'll trust me when I say the above
was not meant to be condescending. I just want to make sure we don't
end up constrained in the design.


--
https://annevankesteren.nl/

[Philip Jägenstedt]

What is the API for serializing and deserializing, is it passing SABs to postMessage? What I'd like to know is if Safari supports it, and thus if what is proposed to ship here matches that.

[Anne van Kesteren]

On Fri, Apr 7, 2017 at 6:08 PM, Philip Jägenstedt <foo...@chromium.org> wrote:
> What is the API for serializing and deserializing, is it passing SABs to
> postMessage?

Yeah.

> What I'd like to know is if Safari supports it, and thus if
> what is proposed to ship here matches that.

As I understand it, the current implementation is likely to match
Safari, but neither is what we'd like it to be. (Copies data across
process boundaries rather than throwing (resulting in a new
messageerror event). And failure to copy is probably a silent error,
as is the case with ArrayBuffer today, which we'd also like to use
this new messageerror.)


--
https://annevankesteren.nl/

[Jochen Eisinger]

We will continue to consider for each feature what the tradeoffs are, so if we decided to ship SharedArrayBuffers as proposed here, that doesn't mean that all other mitigations for hires timers will be removed.

[bi...@google.com]

The current behavior in Chrome is that a SharedArrayBuffer is never copied. Instead, it will still attempt to send a message, even if the receiver can't share it. At that point, the receiver tries to decode the message, fails, and returns a null message instead (as Domenic observed here: https://github.com/whatwg/html/pull/2361#issuecomment-282163852). I've experimented locally with a CL (https://codereview.chromium.org/2809773003) that instead will catch these cases and throw a DataClone error instead.

I tried running the WPT tests in this PR (https://github.com/w3c/web-platform-tests/pull/5003) with this change locally. The current Chrome behavior doesn't allow for passing a SharedArrayBuffer over a MessagePort, which matches the behavior of Firefox, I believe (described by Lars here: https://github.com/whatwg/html/pull/2361#issuecomment-282227073). But this prevents a few of the tests from passing. In addition, Chrome doesn't support nested workers (AIUI) so that prevents a couple more tests from passing.

 

--
https://annevankesteren.nl/

[Anne van Kesteren]

On Tue, Apr 11, 2017 at 7:29 AM, binji via blink-dev
<blin...@chromium.org> wrote:
> The current behavior in Chrome is that a SharedArrayBuffer is never copied.

> I've
> experimented locally with a CL (https://codereview.chromium.org/2809773003)
> that instead will catch these cases and throw a DataClone error instead.

From the API used by the sender? That's not a good design as it
doesn't work for MessageChannel. As discussed in
https://github.com/whatwg/html/issues/936 the only thing that makes
some amount of sense is to dispatch a "messageerror" event on the
receiver. Anything else doesn't work with APIs that do not know who
the receiver might end up being. And I don't think we want
inconsistent behavior across these APIs.


--
https://annevankesteren.nl/

[Philip Jägenstedt]

It sounds like there are still some kinks to work out here, and that blink-dev isn't the place to do that.

Brad, can you check back here when there's some clarity on what Safari has just shipped, and what behavior we hope to all converge on is? This does not mean that there must be consensus among all implementers, if everything comes to an impasse we should reevaluate.

[Dimitri Glazkov]

On Tue, Apr 11, 2017 at 4:50 AM Philip Jägenstedt <foo...@chromium.org> wrote:

It sounds like there are still some kinks to work out here, and that blink-dev isn't the place to do that.

Brad, can you check back here when there's some clarity on what Safari has just shipped, and what behavior we hope to all converge on is? This does not mean that there must be consensus among all implementers, if everything comes to an impasse we should reevaluate.

This sounds like a plan. Ben, Brad -- it sounds like the main concern here is interoperability. Do y'all have clarity on what Philip/Anne are requesting?

:DG<

[Anne van Kesteren]

On Tue, Apr 11, 2017 at 4:35 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:
> This sounds like a plan. Ben, Brad -- it sounds like the main concern here
> is interoperability. Do y'all have clarity on what Philip/Anne are
> requesting?

If I can ask for more favors, would be good to know in
https://github.com/tc39/ecma262/issues/882 or
https://github.com/whatwg/html/pull/2521 what Chrome actually ended up
using to represent an ECMAScript Agent. And how worklets relate to all
of this, though maybe those haven't shipped yet and that question
would be best asked whenever their Intent to Ship arrives...


--
https://annevankesteren.nl/

[Brad]

Anne + Philip,

Thanks for highlighting these items.

It does look like there's some mismatch between implementations when SABs are used in unsupported contexts.

The behavior I'm seeing when a SharedArrayBuffer is used in a context that can't be shared varies.

(I'm using posting one over a MessagePort as a test. Other ones I'm aware of area serialize to IDB, which I assume behaves similarly).

* Chrome - Message is sent, but can't be decoded, so entire postMessages become null.

* Safari - SAB is serialized as an ArrayBuffer (snapshotting current state). This reaches the other side in that form.

* Firefox - TypeError is thrown on the sending side ("SharedArrayBuffer cannot be cloned in this context").

If I understand where Domenic and others are on this, it sounds like perhaps none of these 3 is what we want? (Instead having errors happen on the receiving side).

In any event, I'll try to get responses chimed in each of the issues you reference, and move detailed discussion there.

I suspect the compatibility risk on these is low, given they assume passing SABs in unexpected places, but still figuring that out.

I will report back soon.

Specifically on Worklets, I think we'll likely want them to work, but I assume we can settle it as those standards develop. At least for Audio Worklets, it would be very useful to be able to use a SAB to pass audio data from an audio thread using lock-free techniques. I've been assuming that similar to the main thread, we would not allow futex wait on a worklet.

-BradN

[Joshua Bell]

On the Indexed DB side:

Assuming we don't want to transparently copy the bytes (which it sounds like Safari does), we'll almost certainly want to throw DataCloneError at the point of put(). Having the store operation succeed but silently discard the data, and having the retrieve operation give back a dummy value is a poor developer experience.

[Anne van Kesteren]

On Tue, Apr 11, 2017 at 11:42 PM, Brad <bradn...@chromium.org> wrote:
> Thanks for highlighting these items.
> It does look like there's some mismatch between implementations when SABs
> are used in unsupported contexts.

I think the main issue is that SharedArrayBuffer integration beyond
ECMAScript wasn't completely settled in full detail and while we've
got some help with questions, there was not much in terms of
resources. (It actually ends up impacting HTML, IDL, Notifications,
Indexed DB, worklets, etc. Not all in such a major way as HTML and
IDL, but combined it's quite a bit of work for two people to do on the
side.)

> If I understand where Domenic and others are on this, it sounds like perhaps
> none of these 3 is what we want? (Instead having errors happen on the
> receiving side).

Yeah, and I think for MessageChannel in particular we'd normally want
that to work. It should only fail on the receiving side if you end up
in a different agent cluster (which you cannot know until you
deserialize as the MessagePort could be transferred around a bit).

> I suspect the compatibility risk on these is low, given they assume passing
> SABs in unexpected places, but still figuring that out.

That is probably true. Going outside an agent cluster is a rather
exceptional case (though maybe not as much with cross-origin
<iframe>s), but I would like agreement on a shared plan for what to do
here. That is, will the proposals on the table be implemented within
several releases or are they not feasible for some reason and should
be rethought.


--
https://annevankesteren.nl/

[Philip Jägenstedt]

Yep, short term there's probably not much risk here, a lack of interop in the error handling would take a while to bloom into a compat problem in the wild.

A plan/direction for these issues and tentative sign-off on that by as many implementers as possible would be very good, so that eventual interop is very likely, and then I think we should ship.

The one thing to make sure of is that we don't initially ship something that is less strict as we want, as upgrading a silent failure to an exception or anything like that is usually the wrong direction to move in.

[Domenic Denicola]

From: Philip Jägenstedt [mailto:foo...@chromium.org]

> A plan/direction for these issues and tentative sign-off on that by as many implementers as possible would be very good, so that eventual interop is very likely, and then I think we should ship.

Let me give an update here.

The first thing to understand is that the SharedArrayBuffer feature by itself is solid, baked, well-tested, etc. (Although it would be good to hear if we're running the test262 tests for them.) The outstanding issues are all in web platform integration, and in particular what happens when you try to serialize it and send it to some other realm (e.g. via postMessage).

Anne and I (mostly Anne) have been working on getting the spec and tests fully done over the last week. There are currently three in-flight PRs related to this:

## Define agents and agent clusters: https://github.com/whatwg/html/pull/2521

This defines the "process boundary" within which you can share memory. Although basic cases are straightforward (e.g. same-origin-domain windows that can synchronously reach each other's contents; window-to-its-own-worker), we're also working through the various issues around shared and service workers, worklets, nested workers, and so on. This also defines whether the atomics (futex) APIs work in each type of agent ("process").

The remaining issues here are:

- Apple has a very different model, as mentioned in https://github.com/whatwg/html/pull/2361#issuecomment-280715182 by their engineer working on this. I've pinged him for review of the updated semantics in https://github.com/whatwg/html/pull/2521#issuecomment-294246197 .
- Not everyone agrees on the exact details of who can use the atomics APIs; see details at https://github.com/w3c/web-platform-tests/pull/5569 .
- The story for worklets is very unclear. This is not a big deal since worklets are not shipping anywhere.

## Define messageerror: https://github.com/whatwg/html/pull/2530

This is the new event used when you can't deserialize something into a context---notably, when you try to postMessage a SharedArrayBuffer outside your agent cluster. This is straightforward and people seem to be on-board, although Apple hasn't commented for or against yet. Tests are available at https://github.com/w3c/web-platform-tests/pull/5567.

## Integrate SharedArrayBuffers: https://github.com/whatwg/html/pull/2518

With the above two building blocks in place, we're in good shape to define the structured serialization and deserialization of SABs. The main missing piece is gathering together as many tests as possible, for all the different scenarios where SAB can be serialized and deserialized. This is tracked in https://github.com/w3c/web-platform-tests/pull/5003, where you can see we've created a lot of tests, but still have more to do. I'm planning on working on that next week.

We also need to reflect our recently-arrived-at consensus around what happens when you try to use a SAB in IndexedDB or the Notifications API into the spec and tests. (It should throw, we concluded.)

[Philip Jägenstedt]

Thanks for the abundant details, Domenic. I have just tried to review https://github.com/whatwg/html/pull/2521 which gave me some better understanding of what's going on. Tests will presumably reveal some lack of interop between what Safari is going to ship and what we'd like to ship, but as long as the spec-side discussion has enough eyes on it and in particular that Apple doesn't explicitly object, then I don't think that should be blocking.

LGTM1 to ship this in M60. If any of what's now being spec'd cannot be implemented before shipping, then please file a separate bug for that and mention it here.

Poking at https://github.com/w3ctag/spec-reviews/issues/165 would be nice too, although with Safari already shipping the maneuvering room is very limited.

[Jochen Eisinger]

lgtm2

[Chris Harrelson]

LGTM3 for M60.

lgtm2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Anne van Kesteren]

On Tue, Apr 18, 2017 at 11:39 AM, Philip Jägenstedt <foo...@chromium.org> wrote:
> LGTM1 to ship this in M60. If any of what's now being spec'd cannot be
> implemented before shipping, then please file a separate bug for that and
> mention it here.

We landed all changes to the HTML Standard, a high-level writeup with
pointers to pull requests can be found here:

https://blog.whatwg.org/html-and-shared-memory

Chromium issues filed:

https://bugs.chromium.org/p/chromium/issues/detail?id=711809
https://bugs.chromium.org/p/chromium/issues/detail?id=714582
https://bugs.chromium.org/p/chromium/issues/detail?id=716320


--
https://annevankesteren.nl/