Bug 1460838 - Avoid static initializers in mozjemalloc with MSVC. r=njn

--HG--
extra : rebase_source : dd2106192a90fbade6f89dfa1169c6e9ab3a553b

memory/build/Mutex.h

@@ -93,18 +93,18 @@ struct StaticMutex
 {
   SRWLOCK mMutex;
 
-  constexpr StaticMutex()
-    : mMutex(SRWLOCK_INIT)
-  {
-  }
-
   inline void Lock() { AcquireSRWLockExclusive(&mMutex); }
 
   inline void Unlock() { ReleaseSRWLockExclusive(&mMutex); }
 };
+
+// Normally, we'd use a constexpr constructor, but MSVC likes to create
+// static initializers anyways.
+#define STATIC_MUTEX_INIT SRWLOCK_INIT
+
 #else
-struct StaticMutex : public Mutex
-{
+typedef Mutex StaticMutex;
+
 #if defined(XP_DARWIN)
 #define STATIC_MUTEX_INIT OS_SPINLOCK_INIT
 #elif defined(XP_LINUX) && !defined(ANDROID)
@@ -112,11 +112,7 @@ struct StaticMutex : public Mutex
 #else
 #define STATIC_MUTEX_INIT PTHREAD_MUTEX_INITIALIZER
 #endif
-  constexpr StaticMutex()
-    : Mutex{ STATIC_MUTEX_INIT }
-  {
-  }
-};
+
 #endif
 
 template<typename T>

memory/build/mozjemalloc.cpp

@@ -538,9 +538,20 @@ static void*
 base_alloc(size_t aSize);
 
 // Set to true once the allocator has been initialized.
-static Atomic<bool> malloc_initialized(false);
+#if defined(_MSC_VER) && !defined(__clang__)
+// MSVC may create a static initializer for an Atomic<bool>, which may actually
+// run after `malloc_init` has been called once, which triggers multiple
+// initializations.
+// We work around the problem by not using an Atomic<bool> at all. There is a
+// theoretical problem with using `malloc_initialized` non-atomically, but
+// practically, this is only true if `malloc_init` is never called before
+// threads are created.
+static bool malloc_initialized;
+#else
+static Atomic<bool> malloc_initialized;
+#endif
 
-static StaticMutex gInitLock;
+static StaticMutex gInitLock = { STATIC_MUTEX_INIT };
 
 // ***************************************************************************
 // Statistics data structures.