On 2015/04/29 at 18:27:22, binji wrote:
https://codereview.chromium.org/1069883002/diff/220001/src/accessors.cc
File src/accessors.cc (right):
https://codereview.chromium.org/1069883002/diff/220001/src/accessors.cc#newcode103
src/accessors.cc:103: case JS_SHARED_TYPED_ARRAY_TYPE:
On 2015/04/28 18:31:46, jochen wrote:
> can shared array buffers be neutered?
no, does that affect the code here?
JSArrayBufferViewFieldAccessors include a check whether the underlying
ArrayBuffer is neutered. Also, they blindly assume that the types all derive
from JSArrayBufferView.
And so do the elements() accesses in hydrogen.cc
https://codereview.chromium.org/1069883002/diff/220001/src/runtime/runtime-typedarray.cc#newcode201
src/runtime/runtime-typedarray.cc:201: DCHECK(!array_buffer->is_shared());
On 2015/04/28 18:31:46, jochen wrote:
> why? What about ArrayBuffer.transfer?
I asked about this on the spec doc, but I think it doesn't make much
sense to
add a SharedArrayBuffer.transfer. How would it work if the buffer's backing
store is already being shared across isolates? Either you'd need to have a
synchronization point to swap in the new backing store for all threads (in
which
case you wouldn't neuter) or you'd have to neuter on one thread and
eventually
share the new buffer with the other threads (which wouldn't help with memory
pressure).
AIUI, the only other case for neutering is transferring an ArrayBuffer to
a
Worker, which is the method for sharing a SAB, and does not neuter.
it could detach your local copy and give you a new one that is no longer
shared
across isolates. dunno. it could just not support changing size.
https://codereview.chromium.org/1069883002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
