Bug 742849 - Disable AvailableMemoryTracker for 64-bit Windows processes. r=bsmedberg

xpcom/base/AvailableMemoryTracker.cpp

@@ -501,6 +501,7 @@ namespace AvailableMemoryTracker {
 
 void Activate()
 {
+#if defined(_M_IX86)
   MOZ_ASSERT(sInitialized);
   MOZ_ASSERT(!sHooksActive);
 
@@ -527,21 +528,26 @@ void Activate()
     NS_RegisterMemoryReporter(new NumLowVirtualMemoryEventsMemoryReporter());
   }
   sHooksActive = true;
+#endif
 }
 
 void Init()
 {
+  // Do nothing on x86-64, because nsWindowsDllInterceptor is not thread-safe
+  // on 64-bit.  (On 32-bit, it's probably thread-safe.)  Even if we run Init()
+  // before any other of our threads are running, another process may have
+  // started a remote thread which could call VirtualAlloc!
+  //
+  // Moreover, the benefit of this code is less clear when we're a 64-bit
+  // process, because we aren't going to run out of virtual memory, and the
+  // system is likely to have a fair bit of physical memory.
+
+#if defined(_M_IX86)
   // Don't register the hooks if we're a build instrumented for PGO: If we're
   // an instrumented build, the compiler adds function calls all over the place
   // which may call VirtualAlloc; this makes it hard to prevent
   // VirtualAllocHook from reentering itself.
-
   if (!PR_GetEnv("MOZ_PGO_INSTRUMENTED")) {
-    // Careful, this is not thread-safe!  AddHook sets up the trampoline before
-    // writing to the out param, and anyway, it writes to the function
-    // non-atomically.  So this must happen before any other threads which
-    // might call VirtualAlloc, MapViewOfFile, or CreateDIBSection start up.
-
     sKernel32Intercept.Init("Kernel32.dll");
     sKernel32Intercept.AddHook("VirtualAlloc",
       reinterpret_cast<intptr_t>(VirtualAllocHook),
@@ -557,6 +563,7 @@ void Init()
   }
 
   sInitialized = true;
+#endif
 }
 
 } // namespace AvailableMemoryTracker