[Hacky prototype] Create a shared-memory high-performance reporting service.

services/blamer/public/interfaces/shared_memory_heap_registry.mojom

Index: services/blamer/public/interfaces/shared_memory_heap_registry.mojom
diff --git a/services/blamer/public/interfaces/shared_memory_heap_registry.mojom b/services/blamer/public/interfaces/shared_memory_heap_registry.mojom
new file mode 100644
index 0000000000000000000000000000000000000000..b606ab8f26289b54c23d05c3b7843ce718599778
--- /dev/null
+++ b/services/blamer/public/interfaces/shared_memory_heap_registry.mojom
@@ -0,0 +1,54 @@
+// Copyright 2017 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 blamer.mojom;
+
+// TODO(chrisha): This isn't needed here, and should be moved somewhere else!
+// This is the list of object types that are stored in a
+// blamer::SharedMemoryHeap. They allow thread-safe runtime introspection of
+// remote process blamer state.
+enum DataType {
+  // A node is the fundamental unit in the DAG describing relationships between
+  // logical components at runtime. Internally, nodes have a type (all types
+  // are known at compile time and known by all processes) and an ID (known at
+  // runtime, but guaranteed to be unique, consistent and persistent across all
+  // processes). The DAG has a single root node, which is effectively the
+  // "browser".
+  NODE,
+
+  // A path is from the "browser" root node to any node in the DAG of logical
+  // components. Since the graph is a indeed a DAG and not a tree (nodes can
+  // have multiple parents), the path to a node is not implicit. Many paths are
+  // possible, but not all paths are encoded; only those that have been actually
+  // walked in the DAG at runtime, and for which resource usage measurements
+  // have been explicitly taken in this context.
+  PATH,
+
+  // A measurements object holds resource consumption data that can be
+  // attributed to a given path in the DAG.
+  MEASUREMENTS,
+};
+
+// A slab is a contiguous range of bytes owned by a heap. These are created in
+// the process that owns the heap, and shared with the service.
+struct SharedMemoryHeapSlab {
+  // Shared buffer handle holding the heap slab.
+  handle<shared_buffer> buffer;
+
+  // The size of the heap slab, in bytes.
+  uint32 size;

[Sami, 2017/05/19 13:44:04]

This is set by the client, i.e., renderer, right? Can we trust it?

[chrisha, 2017/05/25 18:05:07]

Good point. We could invert the logic and have the renderer request a slab from
the browser. Slab creation should be infrequent so the round-trip isn't too
expensive.

+
+  // The ID of the slab.
+  uint32 id;
+};
+
+// A shared memory heap is fundamentally owned (and written to) by one process,
+// but is able to be read from any other process. The blamer service maintains
+// a list of all of these heaps across all process types, and is able to inspect
+// them in a thread-safe manner at runtime, coalescing their data to get a
+// global cross-process view of resource consumption.
+interface SharedMemoryHeapRegistry {
+  // Registers a new slab of memory with the blamer service.
+  RegisterSlab(SharedMemoryHeapSlab slab);
+};