WebMessaging: Send transferable ArrayBuffers by copy-and-neuter semantics

WebMessaging: Send transferable ArrayBuffers by copy-and-neuter semantics

Before this CL, MessagePort/ServiceWorker/Client can send an ArrayBuffer with
copy semantics, but it cannot send an ArrayBuffer with move semantics even if
it's specified as a transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, they emulate move semantics by copy-and-neuter semantics that
sends an ArrayBuffer by copy semantics and neuters the original ArrayBuffer.

<Context of this change>

Because of Chromium's multi-process architecture, a target object can be in a
different process from a sender object. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Aokg/edit#

BUG=334408, 511119
Committed: https://crrev.com/99a2756462a76ca70613375784a1a4fa8f3576bb
Cr-Commit-Position: refs/heads/master@{#427015}

[nhiroki, 2016-10-14 12:56:53]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-14 12:57:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-17 07:54:21]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 07:54:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-17 08:36:22]

Patchset #8 (id:130001) has been deleted

[nhiroki, 2016-10-17 08:36:33]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 08:36:45]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-17 10:13:13]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 10:13:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-17 11:00:25]

Patchset #1 (id:1) has been deleted

[nhiroki, 2016-10-17 11:00:34]

Patchset #1 (id:20001) has been deleted

[nhiroki, 2016-10-17 11:01:07]

Patchset #1 (id:40001) has been deleted

[nhiroki, 2016-10-17 11:01:15]

Patchset #1 (id:50001) has been deleted

[nhiroki, 2016-10-17 11:18:03]

Patchset #1 (id:70001) has been deleted

[nhiroki, 2016-10-17 11:24:44]

Patchset #1 (id:90001) has been deleted

[commit-bot: I haz the power, 2016-10-17 11:39:20]

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

[commit-bot: I haz the power, 2016-10-17 11:39:21]

Dry run: This issue passed the CQ dry run.

[nhiroki, 2016-10-17 11:46:22]

Description was changed from

==========
(WIP) WebMessaging: Send a transferable ArrayBuffer over MessagePort by copy

BUG=
==========

to

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object and instead shows a warning message.
(see https://codereview.chromium.org/1301953002)

  // This sends |arrayBuffer| with copy semantics.
  port.postMessage(arrayBuffer);

  // This doesn't send |arrayBuffer| and shows a warning message instead.
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates a move semantics by sending an ArrayBuffer
with copy-and-neuter semantics that copys a src ArrayBuffer to a target and
neuters the src.

<Context of this change>

On the current implementation, a target port can be in a different process from
a sender port. This makes it difficult to support move semantics for
transferable ArrayBuffer because the semantics requires both ports are on the
same process memory space. Using shared memory is a possible solution for the
problem, but that seems to need architectual changes and introduce complexity.
Therefore, as a first step, we support sending a transferable ArrayBuffer with
copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

[nhiroki, 2016-10-17 11:46:37]

Description was changed from

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object and instead shows a warning message.
(see https://codereview.chromium.org/1301953002)

  // This sends |arrayBuffer| with copy semantics.
  port.postMessage(arrayBuffer);

  // This doesn't send |arrayBuffer| and shows a warning message instead.
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates a move semantics by sending an ArrayBuffer
with copy-and-neuter semantics that copys a src ArrayBuffer to a target and
neuters the src.

<Context of this change>

On the current implementation, a target port can be in a different process from
a sender port. This makes it difficult to support move semantics for
transferable ArrayBuffer because the semantics requires both ports are on the
same process memory space. Using shared memory is a possible solution for the
problem, but that seems to need architectual changes and introduce complexity.
Therefore, as a first step, we support sending a transferable ArrayBuffer with
copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

to

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object and instead shows a warning message.
(see https://codereview.chromium.org/1301953002)

  // This sends |arrayBuffer| with copy semantics.
  port.postMessage(arrayBuffer);

  // This doesn't send |arrayBuffer| and shows a warning message instead.
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates a move semantics by sending an ArrayBuffer
with copy-and-neuter semantics that copys a src ArrayBuffer to a target and
neuters the src.

<Context of this change>

On the current implementation, a target port can be in a different process from
a sender port. This makes it difficult to support move semantics for
transferable ArrayBuffer because the semantics requires both ports are on the
same process memory space. Using shared memory is a possible solution for the
problem, but that seems to need architectual changes and introduce complexity.
Therefore, as a first step, we support sending a transferable ArrayBuffer with
copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

[nhiroki, 2016-10-17 11:46:47]

Patchset #1 (id:110001) has been deleted

[nhiroki, 2016-10-17 11:46:59]

Patchset #1 (id:150001) has been deleted

[nhiroki, 2016-10-17 11:51:43]

Description was changed from

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object and instead shows a warning message.
(see https://codereview.chromium.org/1301953002)

  // This sends |arrayBuffer| with copy semantics.
  port.postMessage(arrayBuffer);

  // This doesn't send |arrayBuffer| and shows a warning message instead.
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates a move semantics by sending an ArrayBuffer
with copy-and-neuter semantics that copys a src ArrayBuffer to a target and
neuters the src.

<Context of this change>

On the current implementation, a target port can be in a different process from
a sender port. This makes it difficult to support move semantics for
transferable ArrayBuffer because the semantics requires both ports are on the
same process memory space. Using shared memory is a possible solution for the
problem, but that seems to need architectual changes and introduce complexity.
Therefore, as a first step, we support sending a transferable ArrayBuffer with
copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

to

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object and instead shows a warning message.
(see https://codereview.chromium.org/1301953002)

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead.
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates move semantics by copy-and-neuter semantics
that copys an ArrayBuffer like copy semantics and neuters the ArrayBuffer in the
sender-side.

<Context of this change>

On the current implementation, a target port can be in a different process from
a sender port. This makes it difficult to support move semantics for
transferable ArrayBuffer because the semantics requires both ports are on the
same process memory space. Using shared memory is a possible solution for the
problem, but that seems to need architectual changes and introduce complexity.
Therefore, as a first step, we support sending a transferable ArrayBuffer with
copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

[nhiroki, 2016-10-18 00:29:56]

Description was changed from

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object and instead shows a warning message.
(see https://codereview.chromium.org/1301953002)

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead.
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates move semantics by copy-and-neuter semantics
that copys an ArrayBuffer like copy semantics and neuters the ArrayBuffer in the
sender-side.

<Context of this change>

On the current implementation, a target port can be in a different process from
a sender port. This makes it difficult to support move semantics for
transferable ArrayBuffer because the semantics requires both ports are on the
same process memory space. Using shared memory is a possible solution for the
problem, but that seems to need architectual changes and introduce complexity.
Therefore, as a first step, we support sending a transferable ArrayBuffer with
copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

to

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates move semantics by copy-and-neuter semantics
that copies an ArrayBuffer like copy semantics and neuters the ArrayBuffer in
the sender-side.

<Context of this change>

On the current implementation, a target port can be in a different process from
a sender port. This makes it difficult to support move semantics for
transferable ArrayBuffer because the semantics requires both ports are on the
same process memory space. Using shared memory is a possible solution for the
problem, but that seems to need architectual changes and introduce complexity.
Therefore, as a first step, we support sending a transferable ArrayBuffer with
copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

[nhiroki, 2016-10-18 00:38:51]

Description was changed from

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates move semantics by copy-and-neuter semantics
that copies an ArrayBuffer like copy semantics and neuters the ArrayBuffer in
the sender-side.

<Context of this change>

On the current implementation, a target port can be in a different process from
a sender port. This makes it difficult to support move semantics for
transferable ArrayBuffer because the semantics requires both ports are on the
same process memory space. Using shared memory is a possible solution for the
problem, but that seems to need architectual changes and introduce complexity.
Therefore, as a first step, we support sending a transferable ArrayBuffer with
copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

to

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates move semantics by copy-and-neuter semantics
that copies an ArrayBuffer like copy semantics and neuters the ArrayBuffer in
the sender-side.

<Context of this change>

Because of Chromium's multi-process architecture, a target port can be in a
different process from a sender port. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

[nhiroki, 2016-10-18 01:33:24]

nhiroki@chromium.org changed reviewers:
+ haraken@chromium.org

[nhiroki, 2016-10-18 01:33:25]

haraken@, can you review this or forward this to an appropriate reviewer?
Thanks.

[haraken, 2016-10-18 01:43:53]

Would it be possible to reduce the amount of custom bindings by using
[Custom=CallPrologue]?

However, I'm wondering if we can completely remove the custom bindings.

- Do you know why MessagePort::postMessage doesn't have [PostMessage].
postMessage() methods in other IDL files have [PostMessage].

- Maybe a right fix is 1) to add [PostMessage] to MessagePort::postMessage and
implement the logic in this CL to the generated code for [PostMessage]?

[nhiroki, 2016-10-18 04:10:10]

Thank you for your comments.

On 2016/10/18 01:43:53, haraken wrote:
> Would it be possible to reduce the amount of custom bindings by using
> [Custom=CallPrologue]?
> 
> However, I'm wondering if we can completely remove the custom bindings.
> 
> - Do you know why MessagePort::postMessage doesn't have [PostMessage].
> postMessage() methods in other IDL files have [PostMessage].

It looks to me like MessagePort::postMessage already has [PostMessage]...? My
patch replaces it with [Custom] though.

> - Maybe a right fix is 1) to add [PostMessage] to MessagePort::postMessage and
> implement the logic in this CL to the generated code for [PostMessage]?

Pushing the custom code into a template sounds reasonable. This also enables to
reuse the same logic for ServiceWorker/Client.postMessage etc (see
https://crbug.com/511119).

One thing that I'm concerned is that [PostMessage] template is also used for
in-process workers (e.g., DedicatedWorker and CompositorWorker) already
supporting move semantics. Probably we need to separate the template for
in-process workers and others (e.g., MessagePort, ServiceWorker).

Anyway, I'll try it :)

[nhiroki, 2016-10-18 10:59:54]

Description was changed from

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates move semantics by copy-and-neuter semantics
that copies an ArrayBuffer like copy semantics and neuters the ArrayBuffer in
the sender-side.

<Context of this change>

Because of Chromium's multi-process architecture, a target port can be in a
different process from a sender port. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

to

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates move semantics by copy-and-neuter semantics
that copies an ArrayBuffer like copy semantics and neuters the ArrayBuffer in
the sender-side.

<Context of this change>

Because of Chromium's multi-process architecture, a target port can be in a
different process from a sender port. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

[nhiroki, 2016-10-19 06:13:00]

Description was changed from

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates move semantics by copy-and-neuter semantics
that copies an ArrayBuffer like copy semantics and neuters the ArrayBuffer in
the sender-side.

<Context of this change>

Because of Chromium's multi-process architecture, a target port can be in a
different process from a sender port. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408
==========

to

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates move semantics by copy-and-neuter semantics
that copies an ArrayBuffer like copy semantics and neuters the ArrayBuffer in
the sender-side.

<Context of this change>

Because of Chromium's multi-process architecture, a target port can be in a
different process from a sender port. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119
==========

[nhiroki, 2016-10-19 06:44:19]

Description was changed from

==========
WebMessaging: Send a transferable ArrayBuffer over MessagePort by
copy-and-neuter semantics

Before this CL, MessagePort can send an ArrayBuffer with copy semantics, but it
cannot send an ArrayBuffer with move semantics even if it's specified as a
transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, MessagePort emulates move semantics by copy-and-neuter semantics
that copies an ArrayBuffer like copy semantics and neuters the ArrayBuffer in
the sender-side.

<Context of this change>

Because of Chromium's multi-process architecture, a target port can be in a
different process from a sender port. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119
==========

to

==========
WebMessaging: Send a transferable ArrayBuffer by copy-and-neuter semantics

Before this CL, MessagePort/ServiceWorker/Client can send an ArrayBuffer with
copy semantics, but it cannot send an ArrayBuffer with move semantics even if
it's specified as a transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, they emulate move semantics by copy-and-neuter semantics that
sends an ArrayBuffer by copy semantics and neuters the original ArrayBuffer.

<Context of this change>

Because of Chromium's multi-process architecture, a target object can be in a
different process from a sender object. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119
==========

[nhiroki, 2016-10-19 07:12:28]

Description was changed from

==========
WebMessaging: Send a transferable ArrayBuffer by copy-and-neuter semantics

Before this CL, MessagePort/ServiceWorker/Client can send an ArrayBuffer with
copy semantics, but it cannot send an ArrayBuffer with move semantics even if
it's specified as a transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, they emulate move semantics by copy-and-neuter semantics that
sends an ArrayBuffer by copy semantics and neuters the original ArrayBuffer.

<Context of this change>

Because of Chromium's multi-process architecture, a target object can be in a
different process from a sender object. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119
==========

to

==========
WebMessaging: Send a transferable ArrayBuffer by copy-and-neuter semantics

Before this CL, MessagePort/ServiceWorker/Client can send an ArrayBuffer with
copy semantics, but it cannot send an ArrayBuffer with move semantics even if
it's specified as a transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, they emulate move semantics by copy-and-neuter semantics that
sends an ArrayBuffer by copy semantics and neuters the original ArrayBuffer.

<Context of this change>

Because of Chromium's multi-process architecture, a target object can be in a
different process from a sender object. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119
==========

[nhiroki, 2016-10-19 07:12:34]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[nhiroki, 2016-10-19 07:13:05]

Description was changed from

==========
WebMessaging: Send a transferable ArrayBuffer by copy-and-neuter semantics

Before this CL, MessagePort/ServiceWorker/Client can send an ArrayBuffer with
copy semantics, but it cannot send an ArrayBuffer with move semantics even if
it's specified as a transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, they emulate move semantics by copy-and-neuter semantics that
sends an ArrayBuffer by copy semantics and neuters the original ArrayBuffer.

<Context of this change>

Because of Chromium's multi-process architecture, a target object can be in a
different process from a sender object. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119
==========

to

==========
WebMessaging: Send transferable ArrayBuffers by copy-and-neuter semantics

Before this CL, MessagePort/ServiceWorker/Client can send an ArrayBuffer with
copy semantics, but it cannot send an ArrayBuffer with move semantics even if
it's specified as a transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, they emulate move semantics by copy-and-neuter semantics that
sends an ArrayBuffer by copy semantics and neuters the original ArrayBuffer.

<Context of this change>

Because of Chromium's multi-process architecture, a target object can be in a
different process from a sender object. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119
==========

[nhiroki, 2016-10-19 07:14:48]

Updated. Can you take another look?

I'll add layout tests for ServiceWorker/Client later in this CL because they
depend on this refactoring: https://codereview.chromium.org/2426723004/

[commit-bot: I haz the power, 2016-10-19 09:30:44]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[haraken, 2016-10-19 09:49:28]

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/SerializedScriptValue.cpp
(right):

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/SerializedScriptValue.cpp:357: for
(size_t i = 0; i < arrayBuffers.size(); ++i) {

Can we use an iterator? An index-based access is slow because we have an
out-of-range check.

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/SerializedScriptValue.cpp:370: for
(size_t i = 0; i < arrayBuffers.size(); ++i) {

Ditto.

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/SerializedScriptValue.cpp:390: for
(size_t j = 0; j < bufferHandles.size(); ++j)

Ditto.

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/SerializedScriptValue.cpp:408: for
(size_t j = 0; j < bufferHandles.size(); ++j)

Ditto.

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp
(right):

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp:11562: //
buffers by copy semantics and then neuters the original array

Just to confirm: Your intention is to NOT copy the array buffers (=ignore the
array buffers), right?

[nhiroki, 2016-10-19 12:51:53]

Thank you for reviewing. Comment reply only. I'll update the CL tomorrow.

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp
(right):

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp:11562: //
buffers by copy semantics and then neuters the original array
On 2016/10/19 09:49:28, haraken wrote:
> 
> Just to confirm: Your intention is to NOT copy the array buffers (=ignore the
> array buffers), right?

No. My intention is to copy-transfer the array buffers instead of move-transfer.
Conversely, before this CL, we ignored the array buffers marked with
transferable.

[commit-bot: I haz the power, 2016-10-19 13:14:34]

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

[commit-bot: I haz the power, 2016-10-19 13:14:35]

Dry run: This issue passed the CQ dry run.

[haraken, 2016-10-19 15:40:46]

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp
(right):

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp:11562: //
buffers by copy semantics and then neuters the original array
On 2016/10/19 12:51:53, nhiroki (slow) wrote:
> On 2016/10/19 09:49:28, haraken wrote:
> > 
> > Just to confirm: Your intention is to NOT copy the array buffers (=ignore
the
> > array buffers), right?
> 
> No. My intention is to copy-transfer the array buffers instead of
move-transfer.
> Conversely, before this CL, we ignored the array buffers marked with
> transferable.

I'm a bit confused.

You're ignoring the return value of
SerializedScriptValue::transferArrayBufferContents. Doesn't it mean that you're
only neutering the array buffer without copying to the message?

[nhiroki, 2016-10-20 06:57:58]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-20 06:58:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-20 07:38:13]

Patchset #3 (id:210001) has been deleted

[nhiroki, 2016-10-20 07:38:20]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-20 07:38:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-20 07:40:42]

Patchset #3 (id:230001) has been deleted

[nhiroki, 2016-10-20 07:41:10]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-20 07:41:28]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-20 07:44:03]

Updated. PTAL, thanks!

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/SerializedScriptValue.cpp
(right):

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/SerializedScriptValue.cpp:357: for
(size_t i = 0; i < arrayBuffers.size(); ++i) {
On 2016/10/19 09:49:28, haraken wrote:
> 
> Can we use an iterator? An index-based access is slow because we have an
> out-of-range check.

Done.

(Just to confirm: The out-of-range check indicates RELEASE_ASSERT in
WTF::Vector::at(), right?)

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/SerializedScriptValue.cpp:370: for
(size_t i = 0; i < arrayBuffers.size(); ++i) {
On 2016/10/19 09:49:28, haraken wrote:
> 
> Ditto.

Done.

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/SerializedScriptValue.cpp:390: for
(size_t j = 0; j < bufferHandles.size(); ++j)
On 2016/10/19 09:49:28, haraken wrote:
> 
> Ditto.

Done.

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/SerializedScriptValue.cpp:408: for
(size_t j = 0; j < bufferHandles.size(); ++j)
On 2016/10/19 09:49:28, haraken wrote:
> 
> Ditto.

Done.

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp
(right):

https://codereview.chromium.org/2414333003/diff/190001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/tests/results/core/V8TestObject.cpp:11562: //
buffers by copy semantics and then neuters the original array
On 2016/10/19 15:40:46, haraken wrote:
> On 2016/10/19 12:51:53, nhiroki (slow) wrote:
> > On 2016/10/19 09:49:28, haraken wrote:
> > > 
> > > Just to confirm: Your intention is to NOT copy the array buffers (=ignore
> the
> > > array buffers), right?
> > 
> > No. My intention is to copy-transfer the array buffers instead of
> move-transfer.
> > Conversely, before this CL, we ignored the array buffers marked with
> > transferable.
> 
> I'm a bit confused.
> 
> You're ignoring the return value of
> SerializedScriptValue::transferArrayBufferContents. Doesn't it mean that
you're
> only neutering the array buffer without copying to the message?

SerializedScriptValue::serialize() copies the array buffer into the message
before SerializedScriptValue::transferArrayBufferContents() neuters them.

I guess |transferables.arrayBuffers.clear()| at line 11568 could be confusing.
That doesn't mean serialize() ignores ArrayBuffers in info[0], but means
serialize() handles them as regular objects (non-transferable objects) and
copies them into the message instead. I slightly revised the impl comment.

[haraken, 2016-10-20 09:02:23]

Great, thanks for the clarification. LGTM.

[commit-bot: I haz the power, 2016-10-20 09:04:02]

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

[commit-bot: I haz the power, 2016-10-20 09:04:03]

Dry run: This issue passed the CQ dry run.

[nhiroki, 2016-10-20 10:25:16]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-20 10:25:29]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-20 11:38:07]

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

[commit-bot: I haz the power, 2016-10-20 11:38:08]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[nhiroki, 2016-10-21 01:17:04]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[nhiroki, 2016-10-21 01:17:37]

Patchset #4 (id:270001) has been deleted

[commit-bot: I haz the power, 2016-10-21 01:17:38]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-21 01:57:08]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-21 01:57:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-21 02:03:20]

Patchset #5 (id:310001) has been deleted

[nhiroki, 2016-10-21 02:04:21]

nhiroki@chromium.org changed reviewers:
+ horo@chromium.org

[nhiroki, 2016-10-21 02:04:22]

+horo, can you review http/tests/serviceworker/postmessage.html? Thanks!

[commit-bot: I haz the power, 2016-10-21 03:04:14]

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

[commit-bot: I haz the power, 2016-10-21 03:04:15]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[horo, 2016-10-21 07:26:03]

On 2016/10/21 02:04:22, nhiroki (slow) wrote:
> +horo, can you review http/tests/serviceworker/postmessage.html? Thanks!

As I talked offline, we should have tests for passing a transferable ArrayBuffer
over a MessageChannel to workers.

[nhiroki, 2016-10-21 10:24:46]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-21 10:24:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nhiroki, 2016-10-21 10:27:46]

On 2016/10/21 07:26:03, horo wrote:
> On 2016/10/21 02:04:22, nhiroki (slow) wrote:
> > +horo, can you review http/tests/serviceworker/postmessage.html? Thanks!
> 
> As I talked offline, we should have tests for passing a transferable
ArrayBuffer
> over a MessageChannel to workers.

Added more tests. Can you take another look?

[commit-bot: I haz the power, 2016-10-21 12:13:03]

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

[commit-bot: I haz the power, 2016-10-21 12:13:04]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[nhiroki, 2016-10-21 14:18:40]

The CQ bit was checked by nhiroki@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-21 14:18:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-21 16:12:44]

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

[commit-bot: I haz the power, 2016-10-21 16:12:46]

Dry run: This issue passed the CQ dry run.

[horo, 2016-10-24 03:25:18]

lgtm

[nhiroki, 2016-10-24 03:28:17]

The CQ bit was checked by nhiroki@chromium.org

[nhiroki, 2016-10-24 03:28:18]

The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org
Link to the patchset: https://codereview.chromium.org/2414333003/#ps370001
(title: "fix tests")

[commit-bot: I haz the power, 2016-10-24 03:28:33]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-24 04:56:12]

Description was changed from

==========
WebMessaging: Send transferable ArrayBuffers by copy-and-neuter semantics

Before this CL, MessagePort/ServiceWorker/Client can send an ArrayBuffer with
copy semantics, but it cannot send an ArrayBuffer with move semantics even if
it's specified as a transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, they emulate move semantics by copy-and-neuter semantics that
sends an ArrayBuffer by copy semantics and neuters the original ArrayBuffer.

<Context of this change>

Because of Chromium's multi-process architecture, a target object can be in a
different process from a sender object. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119
==========

to

==========
WebMessaging: Send transferable ArrayBuffers by copy-and-neuter semantics

Before this CL, MessagePort/ServiceWorker/Client can send an ArrayBuffer with
copy semantics, but it cannot send an ArrayBuffer with move semantics even if
it's specified as a transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, they emulate move semantics by copy-and-neuter semantics that
sends an ArrayBuffer by copy semantics and neuters the original ArrayBuffer.

<Context of this change>

Because of Chromium's multi-process architecture, a target object can be in a
different process from a sender object. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119
==========

[commit-bot: I haz the power, 2016-10-24 04:56:14]

Committed patchset #7 (id:370001)

[commit-bot: I haz the power, 2016-10-24 04:58:49]

Description was changed from

==========
WebMessaging: Send transferable ArrayBuffers by copy-and-neuter semantics

Before this CL, MessagePort/ServiceWorker/Client can send an ArrayBuffer with
copy semantics, but it cannot send an ArrayBuffer with move semantics even if
it's specified as a transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, they emulate move semantics by copy-and-neuter semantics that
sends an ArrayBuffer by copy semantics and neuters the original ArrayBuffer.

<Context of this change>

Because of Chromium's multi-process architecture, a target object can be in a
different process from a sender object. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119
==========

to

==========
WebMessaging: Send transferable ArrayBuffers by copy-and-neuter semantics

Before this CL, MessagePort/ServiceWorker/Client can send an ArrayBuffer with
copy semantics, but it cannot send an ArrayBuffer with move semantics even if
it's specified as a transferable object.

  // Copy semantics.
  port.postMessage(arrayBuffer);

  // Move semantics. Currently, this doesn't work and shows a warning message
  // instead. See https://codereview.chromium.org/1301953002
  port.postMessage(arrayBuffer, [arrayBuffer]);

After this CL, they emulate move semantics by copy-and-neuter semantics that
sends an ArrayBuffer by copy semantics and neuters the original ArrayBuffer.

<Context of this change>

Because of Chromium's multi-process architecture, a target object can be in a
different process from a sender object. This makes it difficult to support
zero-copy transfer (move semantics) because it needs to stride over process
memory boundaries. Using shared memory is a possible solution, but that seems to
need architectual changes and introduce complexity. Therefore, as a stopgap, we
support sending a transferable ArrayBuffer with copy-and-neuter semantics.

See this document for more details:
https://docs.google.com/document/d/17o_cjtc3Gk5cDZhoUc37EyhhvBb4wMlCROJvoC2Ao...

BUG=334408, 511119

Committed: https://crrev.com/99a2756462a76ca70613375784a1a4fa8f3576bb
Cr-Commit-Position: refs/heads/master@{#427015}
==========

[commit-bot: I haz the power, 2016-10-24 04:58:50]

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