Intent to Implement: Shared Array Buffers

[Ben Smith]

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.

[Jeffrey Yasskin]

+1 to the idea. Can you elaborate about how you're making sure that Javascript race conditions on elements of SharedArrayBuffers (which have unspecified results) don't become race conditions in C++ code (which have undefined behavior, leading to potential security problems)?

[j...@chromium.org]

+1 here too.

On Friday, April 17, 2015 at 6:42:40 PM UTC-7, Jeffrey Yasskin wrote:

+1 to the idea. Can you elaborate about how you're making sure that Javascript race conditions on elements of SharedArrayBuffers (which have unspecified results) don't become race conditions in C++ code (which have undefined behavior, leading to potential security problems)?

Just to be clear: the C++ race is in developer code compiled to JS, not in the browser's own C++ code. The security issue is therefore not in the browser itself, but in the website. Did I understand properly? If so, I think it means the C++ code already had a race and was UB if that race ever executed, correct? You're asking how the SAB implementation restricts the UB effects that can manifest?

Agreed that the spec should be clear on this. I think right now it says (or at least intends) reads/writes are always restricted to the SAB, and races can be observed as reordering of writes or tearing (if the racy read isn't atomic or is misaligned).

I do think races in developer's code matter. tsan should be usable in SAB, but I'm not sure we can make further guarantees than the ones I mentioned above without sacrificing performance. Implementation experience may happily prove me wrong :-)

[Kinuko Yasuda]

Basically +1 for implementing/experimenting this.

A few questions-- per spec the definition of "worker" could be either worker or main thread.  Are you going to support this on the main thread too?   Also does this intent include worker suspension and wake-up APIs (e.g. futexWait, futexWake)?  Looks like there're questions whether these should be in a form of futex-based design or not, and also how the waiting API should be exposed on the main thread (as we generally try to avoid having blocking API on the main thread).

[oden...@gmail.com]

This is a wonderful approach towards performant JS.

A real world case is scientific simulation which has a compute stage (model "step") and a render stage (model "draw").  Our only real alternative has been webGL, the end of the pipe.  

I might also point out these computations are rapidly moving to TypedArray use, both for performance and for space efficiency (our framework aims at 10's of millions of data values, but nicely fit in a byte. UintArrays are already in use, and the majority of our rendering now uses pixel Uint32 arrays.  Thus "GPU Ready". 

But webGL is often in intractable due to amount of newly computed data loaded to the GPU. Yes, there are lots of ways to minimize the data transfer, but not when interesting amounts of change occur each step .. for example the non-liner location and direction of a particle.

Thus the "step" is really the more interesting form of sharing, but again, web workers suffer from data transfer issues.

Shared buffers would be a game changer for scientific simulation.

   -- Owen

[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

[lha...@mozilla.com]

Regarding whether the suspension/wake will/should be futex-based or not:  There is a new section of the spec coming (soon) with a simple API based around the "synchronic" proposal for C++.  I expect the new API will be easier to use in many cases.  However I expect to keep the futex API for the time being, until we understand whether the synchronic API can replace the futex API in all instances.  I suspect the two APIs will turn out to be complementary, with the synchronic API useful to most hand-written JS and the atomics/futex API useful to asm.js and perhaps also other low-level code.

--lars

[ogi...@gmail.com]

Aside from giving a more C++ feel to the feature, the difference between synchronics and Futexes is that Futexes make two additional guarantees that are costly to performance.  i.e. Futex allows the waker to wake N sleepers and it gives the sleepers a FIFO waking order (in an attempt to provide fairness).  Synchronics don't provide either guarantees so an implementation that just spins is valid, which is essential in HPC at least.

A real-world implementation of synchronics is going to want to spin a bit, yield a bit, then call Futex for long-term sleep.  e.g. This is what I did in my open-source reference implementation: https://code.google.com/p/synchronic/.  (I need to move it, I know...)

I would be wary of giving additional guarantees to new users at least.  I would let them come up with a reason why they must have the FIFO guarantee and can't easily build it themselves... my 2 cents.

Cheers,

Olivier

[Ben Smith]

On Sun, Apr 19, 2015 at 6:20 AM, Kinuko Yasuda <kin...@chromium.org> wrote:

Basically +1 for implementing/experimenting this.

A few questions-- per spec the definition of "worker" could be either worker or main thread.  Are you going to support this on the main thread too?   Also does this intent include worker suspension and wake-up APIs (e.g. futexWait, futexWake)?

I assumed it would be better to keep this intents separate: SharedArrayBuffers, Atomics, wake-up API. Each is progressively more controversial and would require more scrutiny, IMO. You could use SharedArrayBuffers without atomics and fuxtes if you had some other synchronization mechanism (e.g. postMessage), and you could use atomics on SharedArrayBuffers without futex for lock-free data structures. OTOH, the real bang for the buck comes from having all three.

 

  Looks like there're questions whether these should be in a form of futex-based design or not, and also how the waiting API should be exposed on the main thread (as we generally try to avoid having blocking API on the main thread).

We should probably start by preventing blocking the main thread. That said, this intent is currently only for the SharedArrayBuffer part of the API, which has no blocking API.

 

On Sun, Apr 19, 2015 at 9:41 AM, <j...@chromium.org> wrote:

+1 here too.

On Friday, April 17, 2015 at 6:42:40 PM UTC-7, Jeffrey Yasskin wrote:

+1 to the idea. Can you elaborate about how you're making sure that Javascript race conditions on elements of SharedArrayBuffers (which have unspecified results) don't become race conditions in C++ code (which have undefined behavior, leading to potential security problems)?

Just to be clear: the C++ race is in developer code compiled to JS, not in the browser's own C++ code. The security issue is therefore not in the browser itself, but in the website. Did I understand properly? If so, I think it means the C++ code already had a race and was UB if that race ever executed, correct? You're asking how the SAB implementation restricts the UB effects that can manifest?

I'm understanding this as a different question. Let's ignore the C++ that is compiled to JavaScript for now. If two workers race on a SharedArrayBuffer element, then this is equivalent to two C++ threads racing on access to shared memory, which is UB and could have security implications for Blink. I guess this is irrelevant for the JIT case as C++ code generation is bypassed. If the JavaScript is interpreted, perhaps it is enough to implement all SAB accesses on the slow path as relaxed atomics? Not sure the affect on performance this would have, however. Does this sound right, or am I totally off?

[JF Bastien]

On Friday, April 17, 2015 at 6:42:40 PM UTC-7, Jeffrey Yasskin wrote:

+1 to the idea. Can you elaborate about how you're making sure that Javascript race conditions on elements of SharedArrayBuffers (which have unspecified results) don't become race conditions in C++ code (which have undefined behavior, leading to potential security problems)?

Just to be clear: the C++ race is in developer code compiled to JS, not in the browser's own C++ code. The security issue is therefore not in the browser itself, but in the website. Did I understand properly? If so, I think it means the C++ code already had a race and was UB if that race ever executed, correct? You're asking how the SAB implementation restricts the UB effects that can manifest?

I'm understanding this as a different question. Let's ignore the C++ that is compiled to JavaScript for now. If two workers race on a SharedArrayBuffer element, then this is equivalent to two C++ threads racing on access to shared memory, which is UB and could have security implications for Blink. I guess this is irrelevant for the JIT case as C++ code generation is bypassed. If the JavaScript is interpreted, perhaps it is enough to implement all SAB accesses on the slow path as relaxed atomics? Not sure the affect on performance this would have, however. Does this sound right, or am I totally off?

Most compiler-side memory access reordering will already have occurred during the C++ to JS translation, so all that's left is JS to machine code, and realistically the compiler won't reorder memory accesses on the slow path, so all that's left is reordering on the HW side. I therefore don't think that using relaxed would change much: aligned accesses will effectively behave the same whether they're relaxed or non-atomic (HW may reorder either), and unaligned ones will tear depending on which HW you're on and which instructions get generated.

My point was that this shouldn't have security implications for the browser: races in the developer-supplied SAB accesses should only raise UB (and therefore security issues) in the developer-supplies JS code. e.g. the browser has to be careful to avoid TOCTU bugs when it consumes data from SAB.

We can restrict what kind of behavior is observable by racy SAB accesses (i.e. no nasal demons), and we should provide good tooling such as tsan.

[Jeffrey Yasskin]

On Sat, Apr 18, 2015 at 5:41 PM, <j...@chromium.org> wrote:
> +1 here too.
>
>
>
> On Friday, April 17, 2015 at 6:42:40 PM UTC-7, Jeffrey Yasskin wrote:
>>
>> +1 to the idea. Can you elaborate about how you're making sure that
>> Javascript race conditions on elements of SharedArrayBuffers (which have
>> unspecified results) don't become race conditions in C++ code (which have
>> undefined behavior, leading to potential security problems)?
>
>
> Just to be clear: the C++ race is in developer code compiled to JS, not in
> the browser's own C++ code. The security issue is therefore not in the
> browser itself, but in the website. Did I understand properly?

I'm much more worried about the browser's own C++ code. As an example,
the ArrayBuffer interface in v8.h appears to return a (void*,size_t)
pair to let browser C++ code read and modify the contents of the
ArrayBuffer. That interface can never be added for SharedArrayBuffer.
Are we just never going to give browser C++ code access to
SharedArrayBuffer, or is there another mechanism planned?

Jeffrey

[Ben Smith]

You're referring to v8::ArrayBuffer::{GetContents,Externalize}? My WIP blink CL requires these for SharedArrayBuffers as well, though just to forward it to the new SharedArrayBuffer. The initial plan is that no browser code will need to access data in the SAB, though that may change in the future (passing SAB to WebGL, for example). Until that time, maybe the best solution is to remove the Data/ByteLength accessors from the v8::SharedArrayBuffer::Contents API. Hmm, actually I think this won't work because ownership of the memory is passed from v8::SharedArrayBuffer::Contents to WTF::ArrayBufferContents when wrapping it as a DOM object. Do you have a mechanism in mind for how to make this more safe without getting in the way of legitimate use?

 

Jeffrey

[Jeffrey Yasskin]

On Wed, Apr 22, 2015 at 6:06 PM, Ben Smith <bi...@chromium.org> wrote:

On Mon, Apr 20, 2015 at 4:59 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Sat, Apr 18, 2015 at 5:41 PM,  <j...@chromium.org> wrote:
> +1 here too.
>
>
>
> On Friday, April 17, 2015 at 6:42:40 PM UTC-7, Jeffrey Yasskin wrote:
>>
>> +1 to the idea. Can you elaborate about how you're making sure that
>> Javascript race conditions on elements of SharedArrayBuffers (which have
>> unspecified results) don't become race conditions in C++ code (which have
>> undefined behavior, leading to potential security problems)?
>
>
> Just to be clear: the C++ race is in developer code compiled to JS, not in
> the browser's own C++ code. The security issue is therefore not in the
> browser itself, but in the website. Did I understand properly?

I'm much more worried about the browser's own C++ code. As an example,
the ArrayBuffer interface in v8.h appears to return a (void*,size_t)
pair to let browser C++ code read and modify the contents of the
ArrayBuffer. That interface can never be added for SharedArrayBuffer.
Are we just never going to give browser C++ code access to
SharedArrayBuffer, or is there another mechanism planned?

You're referring to v8::ArrayBuffer::{GetContents,Externalize}? My WIP blink CL requires these for SharedArrayBuffers as well, though just to forward it to the new SharedArrayBuffer. The initial plan is that no browser code will need to access data in the SAB, though that may change in the future (passing SAB to WebGL, for example).

"Passing SAB to WebGL" is exactly the sort of thing I'm worried about. It's clearly useful, but you can't use C++ code in WebGL to read the data out of the SAB. V8 will need to provide enough primitives to use the data without giving the C++ compiler access to the actual memory reads.

 

Until that time, maybe the best solution is to remove the Data/ByteLength accessors from the v8::SharedArrayBuffer::Contents API. Hmm, actually I think this won't work because ownership of the memory is passed from v8::SharedArrayBuffer::Contents to WTF::ArrayBufferContents when wrapping it as a DOM object. Do you have a mechanism in mind for how to make this more safe without getting in the way of legitimate use?

Pass around the v8::SharedArrayBuffer::Contents instead of the pointer+size it contains?

[David Levin]

The spec says that this should function for shared workers. Is the proposed blink implementation going to support this?

I'm simply curious.

dave

[Ben Smith]

On Wed, Apr 22, 2015 at 10:45 PM, David Levin <le...@chromium.org> wrote:

The spec says that this should function for shared workers. Is the proposed blink implementation going to support this?

I haven't yet considered this. Is it possible to communicate with a SharedWorker cross-process?

 

I'm simply curious.

dave

On Wed, Apr 22, 2015 at 6:29 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Wed, Apr 22, 2015 at 6:06 PM, Ben Smith <bi...@chromium.org> wrote:

On Mon, Apr 20, 2015 at 4:59 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Sat, Apr 18, 2015 at 5:41 PM,  <j...@chromium.org> wrote:
> +1 here too.
>
>
>
> On Friday, April 17, 2015 at 6:42:40 PM UTC-7, Jeffrey Yasskin wrote:
>>
>> +1 to the idea. Can you elaborate about how you're making sure that
>> Javascript race conditions on elements of SharedArrayBuffers (which have
>> unspecified results) don't become race conditions in C++ code (which have
>> undefined behavior, leading to potential security problems)?
>
>
> Just to be clear: the C++ race is in developer code compiled to JS, not in
> the browser's own C++ code. The security issue is therefore not in the
> browser itself, but in the website. Did I understand properly?

I'm much more worried about the browser's own C++ code. As an example,
the ArrayBuffer interface in v8.h appears to return a (void*,size_t)
pair to let browser C++ code read and modify the contents of the
ArrayBuffer. That interface can never be added for SharedArrayBuffer.
Are we just never going to give browser C++ code access to
SharedArrayBuffer, or is there another mechanism planned?

You're referring to v8::ArrayBuffer::{GetContents,Externalize}? My WIP blink CL requires these for SharedArrayBuffers as well, though just to forward it to the new SharedArrayBuffer. The initial plan is that no browser code will need to access data in the SAB, though that may change in the future (passing SAB to WebGL, for example).

"Passing SAB to WebGL" is exactly the sort of thing I'm worried about. It's clearly useful, but you can't use C++ code in WebGL to read the data out of the SAB. V8 will need to provide enough primitives to use the data without giving the C++ compiler access to the actual memory reads.

I feel like this V8 API is something that can be postponed until we want to access data from the SAB in C++. It doesn't seem like we know exactly how we will use it, so designing the API will be difficult.

 

 

Until that time, maybe the best solution is to remove the Data/ByteLength accessors from the v8::SharedArrayBuffer::Contents API. Hmm, actually I think this won't work because ownership of the memory is passed from v8::SharedArrayBuffer::Contents to WTF::ArrayBufferContents when wrapping it as a DOM object. Do you have a mechanism in mind for how to make this more safe without getting in the way of legitimate use?

Pass around the v8::SharedArrayBuffer::Contents instead of the pointer+size it contains?

Yes, though it seems strange to me that a WTF type would reference a v8 type. I guess instead the DOMSharedArrayBuffer type would reference the v8 types directly instead of using WTF::ArrayBuffer{,Contents}.

 

[David Benjamin]

On Fri, Apr 24, 2015 at 2:42 PM 'Ben Smith' via blink-dev <blin...@chromium.org> wrote:

On Wed, Apr 22, 2015 at 10:45 PM, David Levin <le...@chromium.org> wrote:

The spec says that this should function for shared workers. Is the proposed blink implementation going to support this?

I haven't yet considered this. Is it possible to communicate with a SharedWorker cross-process?

For a multi-process browser, that would require allocating chunks of shared pages between the renderers, no? That seems a ton complexity for not all that much gain. What happens if I try to share thousands of 5-byte buffers between a SharedWorker and a document? You don't even know a priori that these SABs will be sent to a SharedWorker, so that's even more complexity. Either you have to defensively allocate every SAB to pages that can be shared, or you have some mechanism where SABs get promoted to such pages. Which would require synchronizing across all the dedicated workers that the SAB was already shared with.

If the spec supports this, I think we should push back on it. I expect the primary use of this sort of thing would be to port pthreads code over to the web, in which case dedicated workers are just fine. Most platforms distinguish "threads" vs "processes" with sharing memory between the latter being much more involved. So limiting this to things scoped to one document seems not totally without analog.

David

 

[Chris Harrelson]

On Fri, Apr 24, 2015 at 12:37 PM, David Benjamin <davi...@chromium.org> wrote:

On Fri, Apr 24, 2015 at 2:42 PM 'Ben Smith' via blink-dev <blin...@chromium.org> wrote:

On Wed, Apr 22, 2015 at 10:45 PM, David Levin <le...@chromium.org> wrote:

The spec says that this should function for shared workers. Is the proposed blink implementation going to support this?

I haven't yet considered this. Is it possible to communicate with a SharedWorker cross-process?

For a multi-process browser, that would require allocating chunks of shared pages between the renderers, no? That seems a ton complexity for not all that much gain. What happens if I try to share thousands of 5-byte buffers between a SharedWorker and a document? You don't even know a priori that these SABs will be sent to a SharedWorker, so that's even more complexity. Either you have to defensively allocate every SAB to pages that can be shared, or you have some mechanism where SABs get promoted to such pages. Which would require synchronizing across all the dedicated workers that the SAB was already shared with.

If the spec supports this, I think we should push back on it. I expect the primary use of this sort of thing would be to port pthreads code over to the web, in which case dedicated workers are just fine. Most platforms distinguish "threads" vs "processes" with sharing memory between the latter being much more involved. So limiting this to things scoped to one document seems not totally without analog.

What about regular WebWorkers that might be implemented cross-process? The spec currently does not disallow that.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[JF Bastien]

On Fri, Apr 24, 2015 at 12:43 PM, Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Apr 24, 2015 at 12:37 PM, David Benjamin <davi...@chromium.org> wrote:

On Fri, Apr 24, 2015 at 2:42 PM 'Ben Smith' via blink-dev <blin...@chromium.org> wrote:

On Wed, Apr 22, 2015 at 10:45 PM, David Levin <le...@chromium.org> wrote:

The spec says that this should function for shared workers. Is the proposed blink implementation going to support this?

I haven't yet considered this. Is it possible to communicate with a SharedWorker cross-process?

For a multi-process browser, that would require allocating chunks of shared pages between the renderers, no? That seems a ton complexity for not all that much gain. What happens if I try to share thousands of 5-byte buffers between a SharedWorker and a document? You don't even know a priori that these SABs will be sent to a SharedWorker, so that's even more complexity. Either you have to defensively allocate every SAB to pages that can be shared, or you have some mechanism where SABs get promoted to such pages. Which would require synchronizing across all the dedicated workers that the SAB was already shared with.

If the spec supports this, I think we should push back on it. I expect the primary use of this sort of thing would be to port pthreads code over to the web, in which case dedicated workers are just fine. Most platforms distinguish "threads" vs "processes" with sharing memory between the latter being much more involved. So limiting this to things scoped to one document seems not totally without analog.

What about regular WebWorkers that might be implemented cross-process? The spec currently does not disallow that.

Also keep in mind that "atomic" is a guarantee offered to the developer using them, not a requirement on the CPU executing the code. If the CPU can't offer atomicity guarantees when atomics are used properly then atomicity has to be emulated by the runtime, with a lock or locks sharded on address. This is tricky to do cross-process.

[David Benjamin]

On Fri, Apr 24, 2015 at 3:44 PM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Apr 24, 2015 at 12:37 PM, David Benjamin <davi...@chromium.org> wrote:

On Fri, Apr 24, 2015 at 2:42 PM 'Ben Smith' via blink-dev <blin...@chromium.org> wrote:

On Wed, Apr 22, 2015 at 10:45 PM, David Levin <le...@chromium.org> wrote:

The spec says that this should function for shared workers. Is the proposed blink implementation going to support this?

I haven't yet considered this. Is it possible to communicate with a SharedWorker cross-process?

For a multi-process browser, that would require allocating chunks of shared pages between the renderers, no? That seems a ton complexity for not all that much gain. What happens if I try to share thousands of 5-byte buffers between a SharedWorker and a document? You don't even know a priori that these SABs will be sent to a SharedWorker, so that's even more complexity. Either you have to defensively allocate every SAB to pages that can be shared, or you have some mechanism where SABs get promoted to such pages. Which would require synchronizing across all the dedicated workers that the SAB was already shared with.

If the spec supports this, I think we should push back on it. I expect the primary use of this sort of thing would be to port pthreads code over to the web, in which case dedicated workers are just fine. Most platforms distinguish "threads" vs "processes" with sharing memory between the latter being much more involved. So limiting this to things scoped to one document seems not totally without analog.

What about regular WebWorkers that might be implemented cross-process? The spec currently does not disallow that.

The spec wouldn't say anything about processes in general. It still has implications for implementors which choose do to things with multiple processes (or any other implementation strategy). As a random example, the existence of document.domain and a couple other APIs implies that, if foo.example.com does a window.open(bar.example.com), those two documents need to be in the same process. (Obviously you could imagine a UA which manages to serialize and migrate live documents once they can mutually script each other, but Chrome certainly doesn't...)

I believe we currently implement dedicated workers in-process and SharedWorkers out-of-process. The former is a pretty reasonable implementation choice since those workers are going to be same-origin and bound together in lifetime. Whereas we can have multiple documents in one renderer  Likewise the latter is forced on us if we can have two same-origin documents not share a renderer (when they're not in one BrowsingInstance). I dunno if Site Isolation folks have any plans on collapsing that, but I doubt it'd be possible to make that work right before out-of-process iframes.

David
 

[Jeffrey Yasskin]

On Fri, Apr 24, 2015 at 11:33 AM, Ben Smith <bi...@google.com> wrote:

On Wed, Apr 22, 2015 at 6:29 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Wed, Apr 22, 2015 at 6:06 PM, Ben Smith <bi...@chromium.org> wrote:

You're referring to v8::ArrayBuffer::{GetContents,Externalize}? My WIP blink CL requires these for SharedArrayBuffers as well, though just to forward it to the new SharedArrayBuffer. The initial plan is that no browser code will need to access data in the SAB, though that may change in the future (passing SAB to WebGL, for example).

"Passing SAB to WebGL" is exactly the sort of thing I'm worried about. It's clearly useful, but you can't use C++ code in WebGL to read the data out of the SAB. V8 will need to provide enough primitives to use the data without giving the C++ compiler access to the actual memory reads.

I feel like this V8 API is something that can be postponed until we want to access data from the SAB in C++. It doesn't seem like we know exactly how we will use it, so designing the API will be difficult.

Yep, postponing the detailed design seems fine; I just want to have some confidence that whoever does it will run into comments or a reviewer or whatever that reminds them not to use the raw pointers. If we're sure anything like this will go through blink-dev, even that may be enough after this discussion.

Until that time, maybe the best solution is to remove the Data/ByteLength accessors from the v8::SharedArrayBuffer::Contents API. Hmm, actually I think this won't work because ownership of the memory is passed from v8::SharedArrayBuffer::Contents to WTF::ArrayBufferContents when wrapping it as a DOM object. Do you have a mechanism in mind for how to make this more safe without getting in the way of legitimate use?

Pass around the v8::SharedArrayBuffer::Contents instead of the pointer+size it contains?

Yes, though it seems strange to me that a WTF type would reference a v8 type. I guess instead the DOMSharedArrayBuffer type would reference the v8 types directly instead of using WTF::ArrayBuffer{,Contents}.

 

Right, I don't know the architecture well enough to have an opinion on the details; I'm just saying not to expose the raw pointers outside of v8 where someone could accidentally read or write through them, if you have any choice.

Jeffrey

[David Levin]

On Fri, Apr 24, 2015 at 1:03 PM, David Benjamin <davi...@chromium.org> wrote:

On Fri, Apr 24, 2015 at 3:44 PM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Apr 24, 2015 at 12:37 PM, David Benjamin <davi...@chromium.org> wrote:

On Fri, Apr 24, 2015 at 2:42 PM 'Ben Smith' via blink-dev <blin...@chromium.org> wrote:

On Wed, Apr 22, 2015 at 10:45 PM, David Levin <le...@chromium.org> wrote:

The spec says that this should function for shared workers. Is the proposed blink implementation going to support this?

I haven't yet considered this. Is it possible to communicate with a SharedWorker cross-process?

For a multi-process browser, that would require allocating chunks of shared pages between the renderers, no? That seems a ton complexity for not all that much gain. What happens if I try to share thousands of 5-byte buffers between a SharedWorker and a document? You don't even know a priori that these SABs will be sent to a SharedWorker, so that's even more complexity. Either you have to defensively allocate every SAB to pages that can be shared, or you have some mechanism where SABs get promoted to such pages. Which would require synchronizing across all the dedicated workers that the SAB was already shared with.

If the spec supports this, I think we should push back on it. I expect the primary use of this sort of thing would be to port pthreads code over to the web, in which case dedicated workers are just fine. Most platforms distinguish "threads" vs "processes" with sharing memory between the latter being much more involved. So limiting this to things scoped to one document seems not totally without analog.

What about regular WebWorkers that might be implemented cross-process? The spec currently does not disallow that.

The spec wouldn't say anything about processes in general. It still has implications for implementors which choose do to things with multiple processes (or any other implementation strategy). As a random example, the existence of document.domain and a couple other APIs implies that, if foo.example.com does a window.open(bar.example.com), those two documents need to be in the same process. (Obviously you could imagine a UA which manages to serialize and migrate live documents once they can mutually script each other, but Chrome certainly doesn't...)

I believe we currently implement dedicated workers in-process and SharedWorkers out-of-process. The former is a pretty reasonable implementation choice since those workers are going to be same-origin and bound together in lifetime. Whereas we can have multiple documents in one renderer  Likewise the latter is forced on us if we can have two same-origin documents not share a renderer (when they're not in one BrowsingInstance). I dunno if Site Isolation folks have any plans on collapsing that, but I doubt it'd be possible to make that work right before out-of-process iframes.

Yep, it would be ideal not to make out of process iframes harder (and note that iframes have postmessage work for them as well). 

You don't need to support things that will go cross process or this level of complexity but it seems worth considering if it will be possible (i.e. worth the investment of doing it) and that could in turn cause input for the spec.

all the best,

dave