Count m(un)map for each stacktrace in MemoryRegionMap instead of HeapProfileTable.

third_party/tcmalloc/chromium/src/heap-profile-stats.h

Index: third_party/tcmalloc/chromium/src/heap-profile-stats.h
diff --git a/third_party/tcmalloc/chromium/src/heap-profile-stats.h b/third_party/tcmalloc/chromium/src/heap-profile-stats.h
new file mode 100644
index 0000000000000000000000000000000000000000..c2819619835dc913da183d50d3eaf43e0f02450a
--- /dev/null
+++ b/third_party/tcmalloc/chromium/src/heap-profile-stats.h
@@ -0,0 +1,36 @@
+// Copyright (c) 2013 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.
+
+// This file defines structs to accumulate memory allocation and deallocation
+// counts.  These structs are commonly used for malloc (in HeapProfileTable)
+// and mmap (in MemoryRegionMap).
+
+#ifndef HEAP_PROFILE_STATS_H_
+#define HEAP_PROFILE_STATS_H_
+
+struct HeapProfileStats {
+  // Returns true if the two HeapProfileStats are semantically equal.
+  bool Equivalent(const HeapProfileStats& x) const {

[jar (doing other things), 2013/03/08 04:43:31]

nit: avoid use of one letter variables.  Suggest "other" rather than "x".

[Dai Mikurube (NOT FULLTIME), 2013/03/12 08:24:10]

Ok, done.  It was just a move from HeapProfileTable::Stats.

+    return allocs - frees == x.allocs - x.frees &&
+      alloc_size - free_size == x.alloc_size - x.free_size;

[jar (doing other things), 2013/03/08 04:43:31]

nit: indent 4

[Dai Mikurube (NOT FULLTIME), 2013/03/12 08:24:10]

Done.

+  }
+
+  int32 allocs;      // Number of allocation calls.
+  int32 frees;       // Number of free calls.

[jar (doing other things), 2013/03/08 04:43:31]

Why aren't these unsigned?  What is the meaning after overflows?

[Dai Mikurube (NOT FULLTIME), 2013/03/12 08:24:10]

As I wrote above, it's just a move from the existing HeapProfileTable::Stats. 
I'm not sure of the perfect historical reason, but I think we should keep the
types.

+  int64 alloc_size;  // Total size of all allocated objects so far.
+  int64 free_size;   // Total size of all freed objects so far.
+};
+
+// Allocation and deallocation statistics per each stack trace.
+struct HeapProfileBucket : public HeapProfileStats {
+  // Longest stack trace we record.
+  static const int kMaxStackDepth = 32;

[jar (doing other things), 2013/03/08 04:43:31]

Is the intiialization of a static inside a class legal on all our compilers?

[Dai Mikurube (NOT FULLTIME), 2013/03/12 08:24:10]

It works for static and const variables.  We have such initialization for a very
long time.

I heard that it actually fails in a very old compiler "Visual C++ 6.0", but we
should blame the compiler in this case.  It's allowed in the C++03.
http://stackoverflow.com/questions/2605520/c-where-to-initialize-static-const
http://www.devx.com/tips/Tip/5602
http://chanduthedev.blogspot.jp/2012/02/how-to-initialize-const-variable-in-c...

I'm interested in a document that says they're wrong.

Also, these are examples used in the Chromium tree.  (There are more in V8.)
http://src.chromium.org/viewvc/chrome/trunk/src/base/lazy_instance.h?view=markup
http://src.chromium.org/viewvc/chrome/trunk/src/base/time.h?view=markup
http://src.chromium.org/viewvc/chrome/trunk/src/base/metrics/stats_table.h?vi...
http://src.chromium.org/viewvc/chrome/trunk/src/courgette/ensemble.h?view=markup
http://src.chromium.org/viewvc/chrome/trunk/src/net/quic/quic_http_stream_tes...

+
+  uintptr_t hash;           // Hash value of the stack trace.
+  int depth;                // Depth of stack trace.
+  const void** stack;       // Stack trace.
+  HeapProfileBucket* next;  // Next entry in hash-table.
+};
+
+#endif  // HEAP_PROFILE_STATS_H_