Type profiler by intercepting 'new' and 'delete' expressions.

third_party/tcmalloc/chromium/src/gperftools/type_profiler_map.h

Index: third_party/tcmalloc/chromium/src/gperftools/type_profiler_map.h
diff --git a/third_party/tcmalloc/chromium/src/gperftools/type_profiler_map.h b/third_party/tcmalloc/chromium/src/gperftools/type_profiler_map.h
new file mode 100644
index 0000000000000000000000000000000000000000..1901cc0da40809ee3bb3c780b45408abfb858d7b
--- /dev/null
+++ b/third_party/tcmalloc/chromium/src/gperftools/type_profiler_map.h
@@ -0,0 +1,20 @@
+// Copyright 2012 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.
+
+#ifndef TYPE_PROFILER_MAP_H_
+#define TYPE_PROFILER_MAP_H_
+
+#include <typeinfo>
+
+// We don't use PERFTOOLS_DLL_DECL since TypeProfilerMap works only on Linux.
+
+void TypeProfilerInsertType(void* address,

[jar (doing other things), 2012/08/30 16:02:10]

Why isn't this in a namespace?  It seems like you're building up a complex name
to incorporate something akin to a namespace.  Do we have to be at global scope?
 Can we use the namespace you've established for this code (and show
commonality)?

[Dai Mikurube (NOT FULLTIME), 2012/08/31 06:10:30]

I chose the same way with HeapProfiler to consider upstreaming this change.  We
(some Clang guys) were discussing upstreaming such type profile storage in
tcmalloc when we succeed to upstream the Clang modification in future.

But at this time, moving them into the namespace sounds reasonable.  Done.

+                            unsigned int size,
+                            const std::type_info& type);
+
+void TypeProfilerEraseType(void* address);
+
+const std::type_info* TypeProfilerLookupType(const void* address);
+
+#endif  // TYPE_PROFILER_MAP_H_