[tracing] Add sqlite memory statistics to tracing.

sql/process_memory_dump_provider.cc

Index: sql/process_memory_dump_provider.cc
diff --git a/sql/process_memory_dump_provider.cc b/sql/process_memory_dump_provider.cc
new file mode 100644
index 0000000000000000000000000000000000000000..d4adeb683a984ad551387e6aa43871850a906d3a
--- /dev/null
+++ b/sql/process_memory_dump_provider.cc
@@ -0,0 +1,83 @@
+// 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 "sql/process_memory_dump_provider.h"
+
+#include "base/trace_event/memory_dump_manager.h"
+#include "base/trace_event/process_memory_dump.h"
+#include "third_party/sqlite/sqlite3.h"
+
+namespace sql {
+
+// static
+ProcessMemoryDumpProvider* ProcessMemoryDumpProvider::GetInstance() {
+  return Singleton<ProcessMemoryDumpProvider,
+                   LeakySingletonTraits<ProcessMemoryDumpProvider>>::get();
+}
+
+ProcessMemoryDumpProvider::ProcessMemoryDumpProvider() {}
+
+ProcessMemoryDumpProvider::~ProcessMemoryDumpProvider() {}
+
+bool ProcessMemoryDumpProvider::OnMemoryDump(
+    const base::trace_event::MemoryDumpArgs& args,
+    base::trace_event::ProcessMemoryDump* pmd) {
+  int dummy_high_water = -1;
+  int status;
+  int memory_used = -1;
+  status = sqlite3_status(SQLITE_STATUS_MEMORY_USED, &memory_used,
+                          &dummy_high_water, 0 /* resetFlag */);

[Primiano Tucci (use gerrit), 2015/09/30 10:26:56]

ditto: report also the high water mark.
Also, dummy_high_water is a very debatable variable name. 
Perhaps unused_max, or unused_high_watermark (But I'd just use and report it)

[ssid, 2015/10/02 17:06:10]

I was actually dumping the high water using different method. Turns out that
there are 2 methods to get the total size. using that now instead of this
status. Verified both returns the same value.

+  if (status != SQLITE_OK)
+    return false;
+
+  int scratch_size = -1;
+  status = sqlite3_status(SQLITE_STATUS_SCRATCH_USED, &scratch_size,
+                          &dummy_high_water, 0 /* resetFlag */);
+  if (status != SQLITE_OK)
+    return false;
+
+  base::trace_event::MemoryAllocatorDump* dump =
+      pmd->CreateAllocatorDump("sqlite");
+  dump->AddScalar(base::trace_event::MemoryAllocatorDump::kNameSize,
+                  base::trace_event::MemoryAllocatorDump::kUnitsBytes,
+                  memory_used + scratch_size);
+
+  dump->AddScalar("scratch_size",
+                  base::trace_event::MemoryAllocatorDump::kUnitsBytes,
+                  scratch_size);
+  dump->AddScalar("sqlite_malloc_size",

[Primiano Tucci (use gerrit), 2015/09/30 10:26:56]

sqlite_ prefix here seems redundant. This is already in the contexct of a sqlite
dump

[ssid, 2015/10/02 17:06:10]

removed this since it was actually the total.

+                  base::trace_event::MemoryAllocatorDump::kUnitsBytes,
+                  memory_used);
+  dump->AddScalar("high_water_malloc",

[Primiano Tucci (use gerrit), 2015/09/30 10:26:56]

I'd call this malloc_high_wmark_size if you to keep the column name short

[ssid, 2015/10/02 17:06:10]

Done.

+                  base::trace_event::MemoryAllocatorDump::kUnitsBytes,
+                  sqlite3_memory_highwater(1 /*resetFlag */));
+
+  int cache_page_count = -1;
+  status = sqlite3_status(SQLITE_STATUS_PAGECACHE_USED, &cache_page_count,
+                          &dummy_high_water, 0 /* resetFlag */);
+  if (status == SQLITE_OK) {
+    dump->AddScalar("cache_pages",
+                    base::trace_event::MemoryAllocatorDump::kUnitsObjects,

[Primiano Tucci (use gerrit), 2015/09/30 10:26:56]

Hmm not sure the number of pages is really relevant. Is there any way to get
their size?

[ssid, 2015/10/02 17:06:10]

hm no. I don't find any way to get the sizes. I removed them now.

Scratch is allocated from the scratch buffer passed by chrome and chrome does
not set the buffer, so it is always empty.

Cache sizes are added by each connection, and there is no api to get the total
cache size, so removing it.

[Primiano Tucci (use gerrit), 2015/10/06 16:21:21]

Maybe check with OWNERS. If that is actually using memory feels pretty bad not
reporting that.

+                    cache_page_count);
+  }
+
+  int malloc_count = -1;
+  status = sqlite3_status(SQLITE_STATUS_MALLOC_COUNT, &malloc_count,
+                          &dummy_high_water, 0 /* resetFlag */);
+  if (status == SQLITE_OK) {
+    dump->AddScalar("malloc_count",
+                    base::trace_event::MemoryAllocatorDump::kUnitsObjects,
+                    malloc_count);
+  }
+
+  const char* system_allocator_name =
+      base::trace_event::MemoryDumpManager::GetInstance()
+          ->system_allocator_pool_name();
+  if (system_allocator_name) {
+    pmd->AddSuballocation(dump->guid(), system_allocator_name);

[Primiano Tucci (use gerrit), 2015/09/30 10:26:56]

Are you sure that all the scratch + pagecache are sub-allocated from malloc?
By reading the comments looks like only the "malloc" part is malloc-allocated,
and for the rest it might have a page allocator (mmap)
If unsure ask the OWNERS, they'll know more than myself.

[ssid, 2015/10/02 17:06:10]

Sorry about the scratch, I misunderstood. Yes sqlite3_malloc() uses malloc
internally. I verified.

+  }
+  return true;
+}
+
+}  // namespace sql