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

base/allocator/allocated_type_profiler_log.cc

Index: base/allocator/allocated_type_profiler_log.cc
diff --git a/base/allocator/allocated_type_profiler_log.cc b/base/allocator/allocated_type_profiler_log.cc
new file mode 100644
index 0000000000000000000000000000000000000000..f20efe32e09dfe676d8892a9444a569618d4613d
--- /dev/null
+++ b/base/allocator/allocated_type_profiler_log.cc
@@ -0,0 +1,34 @@
+// Copyright (c) 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.
+
+#include "allocated_type_profiler.h"
+#include <iostream>
+
+void* __op_new_intercept__(void* ptr,
+                           size_t size,
+                           const std::type_info& type) {
+  std::cerr << "Allocated "
+            << size
+            << "bytes as an instance of \""
+            << type.name()
+            << "\" at "
+            << ptr
+            << "."
+            << std::endl;

[Ryan Sleevi, 2012/08/10 04:16:09]

style nit: Please see the comments on
http://www.chromium.org/developers/coding-style#TOC-Code-formatting about code
formatting operator<<() calls. (Personal nit) This line breaking format seems to
hinder readability more than help it.

[Dai Mikurube (NOT FULLTIME), 2012/08/10 07:30:03]

Do you mean I should do the following?

std::cerr << "Allocated " << size << " bytes as an instance of \""
          << type.name() << "\" at " << ptr << "." << std::endl;

The _log is used rarely in fact -- it is sometimes turned on when we want to
check this profiler is working correctly for non-tcmalloc commands such as
mksnapshot and protoc.  Such format is good for the purpose.

[Ryan Sleevi, 2012/08/10 09:38:50]

Yes, I believe that to be more readable.
I understood your response to the no-op file being that you explicitly don't
want to interpose for such targets. I had thus assumed logging was for when you
*are* using tcmalloc and you just want to log, rather than actually wire it up
into tcmalloc.

So is this logging file for:
1) no tcmalloc
2) yes tcmalloc

If #1, I'm having trouble understanding the utility of this log?
if #2, could this be incorporated into the tcmalloc file under an #if defined(),
rather than a separate file and target?

[Dai Mikurube (NOT FULLTIME), 2012/08/13 08:32:14]

(1).  Non-tcmalloc binaries are sometimes switched locally from _ignore to _log.
I don't usually need it.

When something is wrong with intercepting, I turn on _log and check if
intercepting is working as expected.  (See the top "summary" for the reason
why I need intercepting for non-tcmalloc...  I cannot turn it off completely.
So I sometimes wanted to check it's correctly intercepted and ignored.)

+  return ptr;
+}
+
+void* __op_delete_intercept__(void* ptr,
+                              size_t size,
+                              const std::type_info& type) {
+  std::cerr << "Dellocated "
+            << size
+            << "bytes of an instance of \""

[Ryan Sleevi, 2012/08/10 04:16:09]

" bytes" (note the extra space)

same on 13

[Dai Mikurube (NOT FULLTIME), 2012/08/10 07:30:03]

Done.

+            << type.name()
+            << "\" at "
+            << ptr
+            << "."
+            << std::endl;

[Ryan Sleevi, 2012/08/10 04:16:09]

perf nit: std::endl is going to force a sync flush every call here. Should you
be using \n instead, and letting the system flush as appropriate?

[Dai Mikurube (NOT FULLTIME), 2012/08/10 07:30:03]

Flushing is better for the purpose written in the reply above.  We don't need
performance here.

+  return ptr;
+}