Use shared memory for moving data over BlobChannel Mojo interface.

blimp/engine/mojo/blob_channel.mojom

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 module blimp.engine.mojom;
 
 interface BlobChannel {
   // Stores the blob |id| in the BlobCache.
-  // TODO(kmarshall): Use shared memory for more efficient data transfer, see
-  // crbug.com/614564 .
-  PutBlob(string id, string data);
+  // The service invokes the no-arg callback after the operation has completed.
+  PutBlob(string id, handle<shared_buffer> data, uint32 size) => ();

[maniscalco, 2016/06/03 16:43:53]

I want to understand the motivation for using shared memory.  You mentioned it's
more efficient.  Is the idea that we'll use less CPU when transferring blobs?

Do you have a feel for where the break even point is?  In other words, I'm
assuming if we've got a 100MB blob, using shared memory will be more efficient,
but if we have a 10B blob, it'll be less efficient (e.g. overhead of
open/mmap/close, etc.).

[Kevin M, 2016/06/03 17:14:57]

The primary reason is that Mojo shares the same IPC pipe with all other features
that need to communicate across the browser/renderer boundary. Pushing large
amounts of data creates contention which can degrade the performance of Chrome.
You can see similar usage for other features which transfer media over Mojo,
e.g. the video decryption or audio output.

A secondary reason is that is that reading and writing 10kb-100kb over a socket
will probably be more overhead than creating a shared buffer, in terms of time
and system resources. This is based on my intuition, though; I haven't written
any tests to prove this empirically.

If the overhead of allocation proves to be too high, I can create a pool for
reusable buffers. However, since the transfers are going to be bursty and will
*not* be steady state, I thought that allocating and immediately freeing is
appropriate, to reduce the space-time application footprint.

[maniscalco, 2016/06/06 15:43:56]

Thanks for the details.

I agree about not implementing a pool mechanism (increases memory use, requires
tuning, increases complexity w/o clear benefit).

Consider adding a comment in this .mojom as to why we're using shared memory.

[Kevin M, 2016/06/09 00:08:32]

Done.

 
   // Requests that the BlobChannel push the blob |id| over the wire.
   // The request will be ignored if the BlobChannel knows that
   // the client already has the data.
   DeliverBlob(string id);
 };