discardable_memory: Using mojo IPC to replace Chrome IPC

components/discardable_memory/public/interfaces/discardable_shared_memory_manager.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 discardable_memory.mojom;
+
+interface DiscardableSharedMemoryManager {

[dcheng, 2016/11/25 00:07:08]

Where does this interface live? Which process is it running in?

I guess it must be the browser process, but it would be nice to have some more
comments about what this interface is for.

[Peng, 2016/11/25 16:41:53]

Right now, it will live in browser process. But in future, for mus+ash, it will
live in the mus process.

Add comments about it.

+  // Allocate a locked discardable shared memory segment.
+  AllocateLockedDiscardableSharedMemory(
+      uint32 size,
+      int32 id) => (handle<shared_buffer> memory);

[dcheng, 2016/11/25 00:07:08]

I know this is just porting an existing API, but I wonder if it would make sense
to:

- represent the handle with an opaque handle interface (similar to
https://codereview.chromium.org/2503813002/)
- have this return a tuple of the opaque interface + a handle to the
shared_buffer
- when the opaque handle is closed, free the shared memory segment.

(My understanding is that with mojo, it's nice to use message pipes and objects
themselves for identity, rather than integer IDs)

[dcheng, 2016/11/25 00:08:05]

(To be clear, it's not necessary to do that here. I'm just wondering if it would
make sense to do this change)

[Peng, 2016/11/25 16:41:53]

Right now, I don't know implementation detail of discardable memory. So I think
it is better
no do it in this CL, maybe we could revisit it later.

+  // Notify manager that a memory segment has been deleted.
+  DeletedDiscardableSharedMemory(int32 id);
+};