Add out-of-process memory logging stream parsing.

chrome/profiling/stack_storage.cc

+// 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.
+
+#include "chrome/profiling/stack_storage.h"
+
+#include "chrome/profiling/stack.h"
+
+namespace profiling {
+
+StackStorage::StackStorage() {}
+
+StackStorage::~StackStorage() {}
+
+StackStorage::Key StackStorage::Insert(Stack&& stack) {
+  base::AutoLock lock(lock_);
+
+  StackStorage::Key key = stacks_.insert(std::move(stack)).first;
+  key->AddRef();
+  return key;
+}
+
+void StackStorage::Free(const Key& key) {
+  base::AutoLock lock(lock_);
+  if (!key->Release())
+    stacks_.erase(key);

[Boris Vidolov, 2017/06/17 03:13:15]

I am wondering if we really need to release stacks - what is the use case? I
understand that we may need to delete them all in the constructor, but probably
not in a public API. In short why bother with this method and the one below, if
it is not needed.

[brettw, 2017/06/19 23:29:46]

I think freeing the stacks makes a big difference in memory usage, but since
this re-land isn't runnable right now I can't test. Otherwise we will keep
stacks around for allocations that are released and freed.

Also, renderer stacks won't match because of oilpan stuff (is my understanding),
so we definitely need to free all stacks associated with a renderer when it
exits.

+}
+
+void StackStorage::Free(const std::vector<Key>& keys) {
+  base::AutoLock lock(lock_);
+  for (size_t i = 0; i < keys.size(); i++) {
+    if (!keys[i]->Release())
+      stacks_.erase(keys[i]);
+  }
+}
+
+const Stack& StackStorage::GetStackForKey(const Key& key) const {
+  // Since the caller should own a reference to the key and the container has
+  // stable iterators, we can access without a lock.
+  return *key;
+}
+
+}  // namespace profiling