[PATCH] Optimize hooks for weakly consistent memory architectures

[GoogleCodeExporter]

The empty list tests for newer hook API does not need an acquire barrier
since InvokeNewHookSlow will call HookList::Traverse which in its turn
will issue the needed acquire barrier.
The same case applies to old hook system where there is no subsequent
load to require an acquire barrier.
This patch optimize both cases by using a NoBarrier_Load. On Intel, which is a 
strong consistent memory architecture, both call will create the same 'mov' 
instruction. However, on PowerPC this avoid two unnecessary 'lwsync' in each 
memory allocation function. 

--- a/src/malloc_hook-inl.h
+++ b/src/malloc_hook-inl.h
@@ -66,7 +66,7 @@ class AtomicPtr {
     // This prevents MSVC 2005, at least, from complaining (it has to
     // do with __wp64; AtomicWord is __wp64, but Atomic32/64 aren't).
     return reinterpret_cast<PtrT>(static_cast<AtomicWord>(
-      base::subtle::Acquire_Load(&data_)));
+      base::subtle::NoBarrier_Load(&data_)));
   }

   // Sets the contained value to new_val and returns the old value,
@@ -124,7 +124,7 @@ struct PERFTOOLS_DLL_DECL HookList {

   // Fast inline implementation for fast path of Invoke*Hook.
   bool empty() const {
-    return base::subtle::Acquire_Load(&priv_end) == 0;
+    return base::subtle::NoBarrier_Load(&priv_end) == 0;
   }

   // This internal data is not private so that the class is an aggregate and can

Original issue reported on code.google.com by zatr...@gmail.com on 25 Jul 2012 at 4:38

[GoogleCodeExporter]

Patch applied and committed to the main trunk.

------------------------------------------------------------------------
r157 | chappedm@gmail.com | 2012-09-17 21:27:34 -0400 (Mon, 17 Sep 2012) | 1 
line

issue-458: Optimizes malloc hooks for weakly consistent memory architectures
------------------------------------------------------------------------

Original comment by chapp...@gmail.com on 18 Sep 2012 at 1:29

• Changed state: Fixed