Re: [blink-dev] Intent to Implement: Shared Array Buffers

[Jochen Eisinger]

+v8-...@googlegroups.com fyi

Note that I'm currently changing the internal implementation of ArrayBuffers. This should be done soon, but please hold off landing bigger changes until then. Tracking bug here: https://code.google.com/p/v8/issues/detail?id=3996

best

-jochen

On Sat, Apr 18, 2015 at 3:18 AM Ben Smith <bi...@chromium.org> wrote:

Contact emails bi...@chromium.org,bradn...@chromium.org Spec https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEqwDdRh4uSoTPSNn77PFk/edit?usp=sharing Summary Adds new JavaScript types SharedArrayBuffer, Shared{Int,Uint}{8,16,32}Array, SharedFloat{32,64}Array and SharedUint8ClampedArray. SharedArrayBuffers can be posted to Workers and without neutering the buffer from the sending side. To be fully useful, additional APIs are needed for atomic reads/writes and synchronization primitives. Motivation Workers can currently share memory by copying or transferring ArrayBuffers. For some cases, this limitation does not perform well enough. Shared memory allows for comparatively lightweight synchronization between workers.

Furthermore, the lack of shared memory prevents many C/C++ applications from being compiled to JavaScript. The current solution requires limiting the application to a single thread, or perhaps emulating threads with an interpreter.

Finally, adding a low-level primitive like shared memory opens the door to higher-level abstractions that can be implemented in JavaScript without adding any new APIs.

The Path to Parallel JavaScript has more detail about the current state of parallel JavaScript and the benefits of extending the web platform with additional parallelism primitives.

Compatibility Risk Firefox: In development Internet Explorer: No public signals Safari: No public signals Web developers: No signals Describe the degree of compatibility risk you believe this change poses Firefox already has an implementation of this in Firefox nightly. IE is moving forward with asm.js support so they may be interested in supporting SharedArrayBuffers as well, though there is currently no public discussion about this.

Many people have concerns about adding shared memory to JavaScript. There are questions of complexity, whether it is necessary ("isn't message passing good enough?"), how it will interact with the JavaScript event loop and existing APIs, etc. Some of these issues are discussed in this blog post. Ongoing technical constraints

SharedArrayBuffers are essentially a parallel hierarchy to the currently implemented ArrayBuffer/TypedArray types. There is a concern about how much code should be/can be shared between the implementations. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no.

Yes. OWP launch tracking bug None yet. Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/4570991992766464 Requesting approval to ship?

No.