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

base/allocator/allocated_type_tcmalloc.cc

Index: base/allocator/allocated_type_tcmalloc.cc
diff --git a/base/allocator/allocated_type_tcmalloc.cc b/base/allocator/allocated_type_tcmalloc.cc
new file mode 100644
index 0000000000000000000000000000000000000000..47fb07c25eb1d0ce74143dd294a939a5eec1e846
--- /dev/null
+++ b/base/allocator/allocated_type_tcmalloc.cc
@@ -0,0 +1,42 @@
+// 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.h"
+#include "allocated_type_tcmalloc.h"
+#include "base/atomicops.h"
+#include <gperftools/allocated_type_map.h>
+#include <gperftools/heap-profiler.h>
+
+volatile static Atomic32 g_enable_intercept = 1;
+
+// Stops the interceptors __op_new_intercept__ and __op_delete_intercept__.
+//
+// The interceptors should be stopped at new/delete between fork and exec.
+// See http://crbug.com/36678.
+
+void StopAllocatedTypeIntercept() {
+  base::subtle::NoBarrier_AtomicExchange(&g_enable_intercept, 0);
+}
+
+void* __op_new_intercept__(void* ptr,
+                           size_t size,
+                           const std::type_info& type) {
+  if (base::subtle::NoBarrier_Load(&g_enable_intercept) != 0) {

[jar (doing other things), 2012/08/07 17:07:34]

You are using atomics as though they are locks.... but they are not.

Note that a thread may sit idle for an arbitrary period of time after executing
line 25.  During that unbounded period, a caller make call
StopAllocatedTypeIntercept().  Sadly, after that point, this thread can awaken
at any time, and execute lines 26 and 27.

I don't see what you are getting from using atomics.  As the atomics.h header
file notes, there are very few reasons to use them (unless you're writing very
special code), and this does not seem to fit that need.

Can you justify why you are using atomics?  Can you explain what this code is
intended to do?

[Dai Mikurube (NOT FULLTIME), 2012/08/08 06:16:23]

I was worried about a rare case that two parallel non-atomic "x = 0;" may result
in "x != 0".

If I remember correctly, it can happen in a few of NUMA CPU memory and cache
consistency models... but as you imagine, I am not sure.  I'll check it again.

My purpose is not locking.  I would like to guarantee "Interceptors are stopped
in a thread when the thread may do new/delete between fork and exec."  It is
just by-effect that interceptors stop in other threads.


On 2012/08/07 17:07:34, jar wrote:

[jar (doing other things), 2012/08/08 23:21:04]

Please cite a reference, or remove the use of atomics here.

I was unable to find mention of this issue when researching NUMA CPU.

On 2012/08/08 06:16:23, Dai Mikurube wrote:

[Dai Mikurube (NOT FULLTIME), 2012/08/09 10:23:53]

It might be my mistake.  Removed Atomic.

+    if (IsHeapProfilerRunning()) {
+      InsertAllocatedType(ptr, size, type);
+    }
+  }
+  return ptr;
+}
+
+void* __op_delete_intercept__(void* ptr,
+                              size_t size,
+                              const std::type_info &type) {
+  if (base::subtle::NoBarrier_Load(&g_enable_intercept) != 0) {
+    if (IsHeapProfilerRunning()) {
+      EraseAllocatedType(ptr);
+    }
+  }
+  return ptr;
+}