[tracing] Add SkResourceCache statistics to chrome://tracing (chrome side)

skia/ext/SkTraceMemoryDump_chrome.cc

+// Copyright 2015 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 "skia/ext/SkTraceMemoryDump_chrome.h"
+
+#include "base/trace_event/memory_allocator_dump.h"
+#include "base/trace_event/memory_dump_manager.h"
+#include "base/trace_event/process_memory_dump.h"
+#include "skia/ext/SkDiscardableMemory_chrome.h"
+
+namespace skia {
+
+SkTraceMemoryDump_Chrome::SkTraceMemoryDump_Chrome(
+    base::trace_event::ProcessMemoryDump* process_memory_dump)
+    : process_memory_dump_(process_memory_dump) {}
+
+SkTraceMemoryDump_Chrome::~SkTraceMemoryDump_Chrome() {}
+
+void SkTraceMemoryDump_Chrome::dumpNumericValue(const char* dumpName,
+                                                const char* valueName,
+                                                const char* units,
+                                                uint64_t value) {
+  auto mad = process_memory_dump_->GetAllocatorDump(dumpName);
+  if (!mad)
+    mad = process_memory_dump_->CreateAllocatorDump(dumpName);
+  mad->AddScalar(valueName, units, value);
+}
+
+void SkTraceMemoryDump_Chrome::setMemoryBacking(const char* dumpName,
+                                                const char* backingType,
+                                                const char* backingObjectId) {
+  if (strcmp(backingType, "malloc") == 0) {
+    auto mad = process_memory_dump_->CreateAllocatorDump(dumpName);

[ericrk, 2015/08/25 20:14:50]

Don't we want to find the existing allocator dump, like in dumpNumericValue?

[ssid, 2015/08/25 20:43:54]

This method will be called only once with a given name. Maybe it should be
enforced that first we set the backing and then add attributes?

[ericrk, 2015/08/25 20:49:56]

Fair enough... it's not really clear from the function names that there's a hard
order for calling these - but would rather not rename at this point.

Can we DCHECK(!GetAllocatorDump(dumpName)) to ensure that you call this first.

[ssid, 2015/08/25 21:03:24]

Hm, you were right, the comment in the api file says this if for existing dumps.
So this should be changed to use get-or-create. But discardable is a special
case here.

+    process_memory_dump_->AddSuballocation(
+        mad->guid(), base::trace_event::MemoryDumpManager::GetInstance()
+                         ->system_allocator_pool_name());
+  }
+}
+
+void SkTraceMemoryDump_Chrome::setDiscardableMemoryBacking(
+    const char* dumpName,
+    const SkDiscardableMemory& discardableMemoryObject) {
+  const SkDiscardableMemoryChrome& memory =
+      reinterpret_cast<const SkDiscardableMemoryChrome&>(

[ericrk, 2015/08/25 20:14:50]

shouldn't we static_cast here?

nit: can we add a comment that there are no other implementations of
SkDiscardableMemory used by Skia when used with Chrome, so we can safely cast?

[ssid, 2015/08/25 20:43:54]

Yes, it should be static_cast.

+          discardableMemoryObject);
+  auto mad = memory.CreateMemoryAllocatorDump(dumpName, process_memory_dump_);

[ericrk, 2015/08/25 20:14:49]

same as above, should this try to find an existing dump? Should we add a helper
function "CreateOrFindAllocatorDump" or something?

[ssid, 2015/08/25 20:43:54]

hm, the issue is, this goes all the way into implementations of
base::DiscardableMemory. All of these asume that the dump does not exist. So, I
think this should also assume that the dump does not exist already. But, maybe
the setMemoryBacking can be changed to use getOrCreate.

[ericrk, 2015/08/25 20:49:56]

See my comment above... I'm OK with a DCHECK.

+  DCHECK(mad);
+}
+
+}  // namespace skia