Bug 1395776 - Make _recalloc, _expand and _msize go through replace-malloc when enabled. r?njn draft
authorMike Hommey <mh+mozilla@glandium.org>
Thu, 31 Aug 2017 14:17:49 +0900
changeset 657378 75f3770b925b3c912d8624feba23da3a407d8287
parent 657377 eebe37f24a0e980fe1dd6da2c2d00ae8dbd6ab00
child 729413 cfeba343fb6e1bc17b6fab71b15db501a10455cc
push id77505
push userbmo:mh+mozilla@glandium.org
push dateFri, 01 Sep 2017 10:54:09 +0000
reviewersnjn
bugs1395776
milestone57.0a1
Bug 1395776 - Make _recalloc, _expand and _msize go through replace-malloc when enabled. r?njn
memory/mozjemalloc/mozjemalloc.cpp
--- a/memory/mozjemalloc/mozjemalloc.cpp
+++ b/memory/mozjemalloc/mozjemalloc.cpp
@@ -5116,62 +5116,16 @@ template<> inline void
 MozJemalloc::jemalloc_purge_freed_pages()
 {
   /* Do nothing. */
 }
 
 #endif /* defined MALLOC_DOUBLE_PURGE */
 
 
-
-#ifdef XP_WIN
-//TODO: these three functions should be rerouted through replace-malloc
-void*
-_recalloc(void* aPtr, size_t aCount, size_t aSize)
-{
-  size_t oldsize = aPtr ? isalloc(aPtr) : 0;
-  size_t newsize = aCount * aSize;
-
-  /*
-   * In order for all trailing bytes to be zeroed, the caller needs to
-   * use calloc(), followed by recalloc().  However, the current calloc()
-   * implementation only zeros the bytes requested, so if recalloc() is
-   * to work 100% correctly, calloc() will need to change to zero
-   * trailing bytes.
-   */
-
-  aPtr = MozJemalloc::realloc(aPtr, newsize);
-  if (aPtr && oldsize < newsize) {
-    memset((void*)((uintptr_t)aPtr + oldsize), 0, newsize - oldsize);
-  }
-
-  return aPtr;
-}
-
-/*
- * This impl of _expand doesn't ever actually expand or shrink blocks: it
- * simply replies that you may continue using a shrunk block.
- */
-void*
-_expand(void* aPtr, size_t newsize)
-{
-  if (isalloc(aPtr) >= newsize) {
-    return aPtr;
-  }
-
-  return nullptr;
-}
-
-size_t
-_msize(void* aPtr)
-{
-  return MozJemalloc::malloc_usable_size(aPtr);
-}
-#endif
-
 template<> inline void
 MozJemalloc::jemalloc_free_dirty_pages(void)
 {
   size_t i;
   malloc_spin_lock(&arenas_lock);
   for (i = 0; i < narenas; i++) {
     arena_t* arena = arenas[i];
 
@@ -5523,16 +5477,58 @@ MOZ_EXPORT void* (*__memalign_hook)(size
  * XXX On systems that support RTLD_GROUP or DF_1_GROUP, do their
  * implementations permit similar inconsistencies?  Should STV_SINGLETON
  * visibility be used for interposition where available?
  */
 #    error "Interposing malloc is unsafe on this system without libc malloc hooks."
 #endif
 
 #ifdef XP_WIN
+void*
+_recalloc(void* aPtr, size_t aCount, size_t aSize)
+{
+  size_t oldsize = aPtr ? isalloc(aPtr) : 0;
+  size_t newsize = aCount * aSize;
+
+  /*
+   * In order for all trailing bytes to be zeroed, the caller needs to
+   * use calloc(), followed by recalloc().  However, the current calloc()
+   * implementation only zeros the bytes requested, so if recalloc() is
+   * to work 100% correctly, calloc() will need to change to zero
+   * trailing bytes.
+   */
+
+  aPtr = DefaultMalloc::realloc(aPtr, newsize);
+  if (aPtr && oldsize < newsize) {
+    memset((void*)((uintptr_t)aPtr + oldsize), 0, newsize - oldsize);
+  }
+
+  return aPtr;
+}
+
+/*
+ * This impl of _expand doesn't ever actually expand or shrink blocks: it
+ * simply replies that you may continue using a shrunk block.
+ */
+void*
+_expand(void* aPtr, size_t newsize)
+{
+  if (isalloc(aPtr) >= newsize) {
+    return aPtr;
+  }
+
+  return nullptr;
+}
+
+size_t
+_msize(void* aPtr)
+{
+  return DefaultMalloc::malloc_usable_size(aPtr);
+}
+
 /*
  * In the new style jemalloc integration jemalloc is built as a separate
  * shared library.  Since we're no longer hooking into the CRT binary,
  * we need to initialize the heap at the first opportunity we get.
  * DLL_PROCESS_ATTACH in DllMain is that opportunity.
  */
 BOOL APIENTRY DllMain(HINSTANCE hModule,
                       DWORD reason,