Implement SharedArrayBuffer

Implement SharedArrayBuffer.

This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer
under the hood. It can be distinguished from an ArrayBuffer by the newly-added
is_shared() bit.

Currently there is no difference in functionality between a SharedArrayBuffer
and an ArrayBuffer. However, a future CL will add the Atomics API, which is
only available on an SharedArrayBuffer. All non-atomic accesses are identical
to ArrayBuffer accesses.

LOG=N
BUG=

Committed: https://crrev.com/aff8ebb0ebe165dceb03b567fe54633cf3f0a1f7
Cr-Commit-Position: refs/heads/master@{#28594}

[binji, 2015-05-14 19:00:02]

FYI: here is an example CL where the TypedArray hierarchy is not split.

[binji, 2015-05-21 14:05:20]

binji@chromium.org changed reviewers:
+ jochen@chromium.org

[binji, 2015-05-21 14:05:21]

PTAL, changed this to use a flag on JSArrayBuffer instead of introducing a new
InstanceType.

[jochen (gone - plz use gerrit), 2015-05-22 08:37:47]

https://codereview.chromium.org/1136553006/diff/80001/include/v8.h
File include/v8.h (right):

https://codereview.chromium.org/1136553006/diff/80001/include/v8.h#newcode5171
include/v8.h:5171: ArrayBuffer::Allocator* shared_array_buffer_allocator;
why do we need a separate allocator?

https://codereview.chromium.org/1136553006/diff/80001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/1136553006/diff/80001/src/objects.h#newcode177
src/objects.h:177: enum SharedFlag { NOT_SHARED, SHARED };
not needed?

[binji, 2015-05-22 09:27:34]

https://codereview.chromium.org/1136553006/diff/80001/include/v8.h
File include/v8.h (right):

https://codereview.chromium.org/1136553006/diff/80001/include/v8.h#newcode5171
include/v8.h:5171: ArrayBuffer::Allocator* shared_array_buffer_allocator;
On 2015/05/22 at 08:37:47, jochen wrote:
> why do we need a separate allocator?

We probably don't. Removed.

https://codereview.chromium.org/1136553006/diff/80001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/1136553006/diff/80001/src/objects.h#newcode177
src/objects.h:177: enum SharedFlag { NOT_SHARED, SHARED };
On 2015/05/22 at 08:37:47, jochen wrote:
> not needed?

It was suggested in the other CL that this would make some of the callsites
clearer. But no, not strictly needed. Wdyt?

[Jarin, 2015-05-22 09:37:34]

jarin@chromium.org changed reviewers:
+ jarin@chromium.org

[Jarin, 2015-05-22 09:37:35]

https://codereview.chromium.org/1136553006/diff/80001/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/1136553006/diff/80001/src/objects.h#newcode177
src/objects.h:177: enum SharedFlag { NOT_SHARED, SHARED };
On 2015/05/22 09:27:34, binji wrote:
> On 2015/05/22 at 08:37:47, jochen wrote:
> > not needed?
> 
> It was suggested in the other CL that this would make some of the callsites
> clearer. But no, not strictly needed. Wdyt?

Indeed, I suggested that for making it clear at call sites what the argument
does. We do this in other parts of v8 and I like that. (And it was suggested to
me to use enum for function arguments when I joined v8). 

Some related reading material:
https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/

[jochen (gone - plz use gerrit), 2015-05-22 09:41:16]

On 2015/05/22 at 09:37:35, jarin wrote:
> https://codereview.chromium.org/1136553006/diff/80001/src/objects.h
> File src/objects.h (right):
> 
> https://codereview.chromium.org/1136553006/diff/80001/src/objects.h#newcode177
> src/objects.h:177: enum SharedFlag { NOT_SHARED, SHARED };
> On 2015/05/22 09:27:34, binji wrote:
> > On 2015/05/22 at 08:37:47, jochen wrote:
> > > not needed?
> > 
> > It was suggested in the other CL that this would make some of the callsites
> > clearer. But no, not strictly needed. Wdyt?
> 
> Indeed, I suggested that for making it clear at call sites what the argument
does. We do this in other parts of v8 and I like that. (And it was suggested to
me to use enum for function arguments when I joined v8). 
> 
> Some related reading material:
https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/

ok

can we make it an enum class then? with that this looks good

[binji, 2015-05-22 10:12:01]

On 2015/05/22 at 09:41:16, jochen wrote:
> On 2015/05/22 at 09:37:35, jarin wrote:
> > https://codereview.chromium.org/1136553006/diff/80001/src/objects.h
> > File src/objects.h (right):
> > 
> >
https://codereview.chromium.org/1136553006/diff/80001/src/objects.h#newcode177
> > src/objects.h:177: enum SharedFlag { NOT_SHARED, SHARED };
> > On 2015/05/22 09:27:34, binji wrote:
> > > On 2015/05/22 at 08:37:47, jochen wrote:
> > > > not needed?
> > > 
> > > It was suggested in the other CL that this would make some of the
callsites
> > > clearer. But no, not strictly needed. Wdyt?
> > 
> > Indeed, I suggested that for making it clear at call sites what the argument
does. We do this in other parts of v8 and I like that. (And it was suggested to
me to use enum for function arguments when I joined v8). 
> > 
> > Some related reading material:
https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/
> 
> ok
> 
> can we make it an enum class then? with that this looks good

Done.

[jochen (gone - plz use gerrit), 2015-05-22 11:13:10]

lgtm

please also wait for jarin@

[Jarin, 2015-05-22 11:45:19]

On 2015/05/22 11:13:10, jochen wrote:
> lgtm
> 
> please also wait for jarin@

lgtm. However, we should have a cctest that creates two isolates sharing one
shared array buffer, where one isolate writes into the buffer and the other
isolate should see the written values. wdyt?

[binji, 2015-05-22 11:52:33]

On 2015/05/22 at 11:45:19, jarin wrote:
> On 2015/05/22 11:13:10, jochen wrote:
> > lgtm
> > 
> > please also wait for jarin@
> 
> lgtm. However, we should have a cctest that creates two isolates sharing one
shared array buffer, where one isolate writes into the buffer and the other
isolate should see the written values. wdyt?

OK, I can add a test for that. Though it is possible to do this with ArrayBuffer
as well, so it would not be testing any particular details of SharedArrayBuffer.

[binji, 2015-05-22 11:59:18]

On 2015/05/22 at 11:52:33, binji wrote:
> On 2015/05/22 at 11:45:19, jarin wrote:
> > On 2015/05/22 11:13:10, jochen wrote:
> > > lgtm
> > > 
> > > please also wait for jarin@
> > 
> > lgtm. However, we should have a cctest that creates two isolates sharing one
shared array buffer, where one isolate writes into the buffer and the other
isolate should see the written values. wdyt?
> 
> OK, I can add a test for that. Though it is possible to do this with
ArrayBuffer as well, so it would not be testing any particular details of
SharedArrayBuffer.

After discussing this with jarin@, we've decided that it is not a particularly
useful test. I'll add thread tests for later Atomics CLs.

[binji, 2015-05-22 11:59:51]

The CQ bit was checked by binji@chromium.org

[commit-bot: I haz the power, 2015-05-22 12:00:02]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1136553006/120001

[commit-bot: I haz the power, 2015-05-22 12:07:09]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2015-05-22 12:07:28]

Patchset 7 (id:??) landed as
https://crrev.com/57170bff7baf341c666252a7f6a49e9c08d51263
Cr-Commit-Position: refs/heads/master@{#28588}

[Yang, 2015-05-22 12:17:34]

A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/1149203003/ by yangguo@chromium.org.

The reason for reverting is: breaks build.

[binji, 2015-05-22 12:43:59]

On 2015/05/22 at 12:17:34, yangguo wrote:
> A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/1149203003/ by yangguo@chromium.org.
> 
> The reason for reverting is: breaks build.

Bumping embedder index to 80, and relanding.

[binji, 2015-05-22 12:45:44]

The CQ bit was checked by binji@chromium.org

[binji, 2015-05-22 12:45:44]

The patchset sent to the CQ was uploaded after l-g-t-m from jarin@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1136553006/#ps140001
(title: "fix embedder index")

[commit-bot: I haz the power, 2015-05-22 12:45:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1136553006/140001

[commit-bot: I haz the power, 2015-05-22 12:51:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-05-22 12:51:08]

Try jobs failed on following builders:
  v8_linux64_avx2_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel/builds/672)

[binji, 2015-05-22 13:00:49]

The CQ bit was checked by binji@chromium.org

[binji, 2015-05-22 13:00:50]

The patchset sent to the CQ was uploaded after l-g-t-m from jarin@chromium.org,
jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1136553006/#ps160001
(title: "merge master")

[commit-bot: I haz the power, 2015-05-22 13:01:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1136553006/160001

[commit-bot: I haz the power, 2015-05-22 13:43:47]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2015-05-22 13:44:00]

Patchset 9 (id:??) landed as
https://crrev.com/aff8ebb0ebe165dceb03b567fe54633cf3f0a1f7
Cr-Commit-Position: refs/heads/master@{#28594}