https://codereview.chromium.org/1069883002/diff/220001/include/v8.h
File include/v8.h (right):
https://codereview.chromium.org/1069883002/diff/220001/include/v8.h#newcode3684
include/v8.h:3684: class V8_EXPORT Allocator { // NOLINT
On 2015/04/28 18:31:46, jochen wrote:
why can't we use the allocator form ArrayBuffer?
Done.
https://codereview.chromium.org/1069883002/diff/220001/include/v8.h#newcode3751
include/v8.h:3751: size_t byte_length);
On 2015/04/28 18:31:46, jochen wrote:
we should have a version that creates an internalized shared array
buffer
Done.
https://codereview.chromium.org/1069883002/diff/220001/include/v8.h#newcode3769
include/v8.h:3769: Contents Externalize();
On 2015/04/28 18:31:46, jochen wrote:
also add GetContents() that gets the contents without externalizing
Done.
https://codereview.chromium.org/1069883002/diff/220001/include/v8.h#newcode6081
include/v8.h:6081: static void SetSharedArrayBufferAllocator(
On 2015/04/28 18:31:46, jochen wrote:
the allocator should be per isolate and passed in via CreateParams.
I'll change
the array buffer one soon to follow this pattern.
Done.
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?
https://codereview.chromium.org/1069883002/diff/220001/src/harmony-sharedtypedarray.js
File src/harmony-sharedtypedarray.js (right):
https://codereview.chromium.org/1069883002/diff/220001/src/harmony-sharedtypedarray.js#newcode86
src/harmony-sharedtypedarray.js:86: %_TypedArrayInitialize(obj,
ARRAY_ID, null, 0, byteLength);
On 2015/04/28 18:31:46, jochen wrote:
what's the point of having an on-heap shared typed array?
Done.
https://codereview.chromium.org/1069883002/diff/220001/src/objects.h
File src/objects.h (right):
https://codereview.chromium.org/1069883002/diff/220001/src/objects.h#newcode10267
src/objects.h:10267: inline SharedFlag is_shared();
On 2015/04/28 18:31:46, jochen wrote:
why is that not just a bool like the other bits?
Done.
https://codereview.chromium.org/1069883002/diff/220001/src/runtime/runtime-typedarray.cc
File src/runtime/runtime-typedarray.cc (right):
https://codereview.chromium.org/1069883002/diff/220001/src/runtime/runtime-typedarray.cc#newcode79
src/runtime/runtime-typedarray.cc:79: bool is_shared =
array_buffer->is_shared();
On 2015/04/29 04:46:01, jarin wrote:
This should be array_buffer->is_shared() == SHARED. Or just make
JSArrayBuffer::is_shared return bool, the main motivation for the
SharedFlag is
to make the sharing explicit when passed as a parameter.
(That said, I am a bit surprised that C++ is happy about using enum as
bool.)
Done.
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.
https://codereview.chromium.org/1069883002/diff/220001/tools/gyp/v8.gyp
File tools/gyp/v8.gyp (right):
https://codereview.chromium.org/1069883002/diff/220001/tools/gyp/v8.gyp#newcode1733
tools/gyp/v8.gyp:1733: '../../src/harmony-sharedtypedarray.js',
On 2015/04/28 18:31:46, jochen wrote:
please also update BUILD.gn
Done.
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.
