tcmalloc: Use C++11 atomics where appropriate.

third_party/tcmalloc/chromium/src/base/atomicops_internals_portable.h

Index: third_party/tcmalloc/chromium/src/base/atomicops_internals_portable.h
diff --git a/base/atomicops_internals_portable.h b/third_party/tcmalloc/chromium/src/base/atomicops_internals_portable.h
similarity index 97%
copy from base/atomicops_internals_portable.h
copy to third_party/tcmalloc/chromium/src/base/atomicops_internals_portable.h
index d28561076dd5f300710c090ebc6d67cca2888b39..f62c8f6468b8aa3efc133b8489c4424e2aa56bda 100644
--- a/base/atomicops_internals_portable.h
+++ b/third_party/tcmalloc/chromium/src/base/atomicops_internals_portable.h
@@ -33,6 +33,10 @@
 #define BASE_ATOMICOPS_INTERNALS_PORTABLE_H_
 
 #include <atomic>
+#include <stdint.h>
+
+typedef int32_t Atomic32;
+#define BASE_HAS_ATOMIC64 1  // Use only in tests and base/atomic*

[JF, 2015/12/26 00:27:24]

I'm not sure I understand the comment: isn't this force-defining the 64-bit
versions of atomic functions for all users?

[Nico, 2015/12/26 04:13:03]

It's like this in the x86 version this patch deleted, and it's used in
atomicops.h. I understood the comment to mean that you shouldn't check for this
define except in comments and (tcmalloc's) base/.

[JF, 2015/12/26 15:56:15]

Is it required though? If so, could we only support 64-bit atomics on x86-64?

I'd wary of supporting 64-bit atomics on non-64-bit platforms: older MIPS don't
have lock-free 64-bit atomics, and ARM has fairly expensive ones (they're
useful, but perf really needs to be measured when used).

[Nico, 2015/12/26 16:35:05]

In practice, there are three non-test uses of atomicops in tcmalloc
(https://code.google.com/p/chromium/codesearch#search/&q=atomicops.h%5C%22%20f...):

1. spinlock_internal uses an atomic32:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/tcmall...

2. vdso_support (only used on 32-bit linux and can probably be removed there
too) uses a call to MemoryBarrier:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/tcmall...

3. AtomicPtr uses an AtomicWord:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/tcmall...

So 64-bit atomics are only used on 64-bit platforms, via the third use (if that
code is life at all). tcmalloc doesn't change much, so I don't think this list
of uses will fluctuate a lot.

The old code used to define BASE_HAS_ATOMIC64 for 32-bit x86 too, so I figured
I'd do this too, and if this is defined then atomicops defines functions that
forward from the global namespace to base::subtle (with a TODO to remove these
forwarders). I could delete those, but I'd prefer if we didn't diverge more from
upstream tcmalloc than necessary.

[JF, 2015/12/26 16:58:37]

OK thanks for looking into it!

Yes, I think 2 can also be removed, but agree with you that less divergence is
good.

 
 namespace base {
 namespace subtle {
@@ -137,7 +141,8 @@ inline Atomic32 Release_Load(volatile const Atomic32* ptr) {
   return ((AtomicLocation32)ptr)->load(std::memory_order_relaxed);
 }
 
-#if defined(ARCH_CPU_64_BITS)
+#if defined(BASE_HAS_ATOMIC64)
+typedef int64_t Atomic64;
 
 typedef volatile std::atomic<Atomic64>* AtomicLocation64;
 static_assert(sizeof(*(AtomicLocation64) nullptr) == sizeof(Atomic64),
@@ -219,8 +224,7 @@ inline Atomic64 Release_Load(volatile const Atomic64* ptr) {
   MemoryBarrier();
   return ((AtomicLocation64)ptr)->load(std::memory_order_relaxed);
 }
-
-#endif  // defined(ARCH_CPU_64_BITS)
+#endif  // defined(BASE_HAS_ATOMIC64)
 }  // namespace subtle
 }  // namespace base