Mike Hommey 8b2a1911b2 Bug 1559379 - Export C++ allocation functions from mozglue on all platforms. r=froydnj ... - On Android, we were already doing it, but using fallible allocations. - On *nix, it probably doesn't make a difference, but can't hurt. For most things in Gecko, operator new/delete are inlined and thus replaced by direct calls to the underlying allocator functions (moz_xmalloc, malloc, etc.). This may have a benefit for some third party libraries that would otherwise go through libstdc++'s to eventually end up back into our allocator via the zone allocator on macOS and via the exported symbols on others. - On Windows, because of how some CRT static libraries are, a non-inlined operator new (thanks to some disabled STL wrapping) would end up linked against the system malloc, causing problems. Overall, this can only be better. This also reduces the number of places where we define those functions. And on Android, this means operator new within mozglue becomes infallible, which is more consistent with everything else. Differential Revision: https://phabricator.services.mozilla.com/D36166 --HG-- extra : moz-landing-system : lando		2019-06-27 22:07:42 +00:00
..
fallback.cpp
Makefile.in
malloc_decls.h
moz.build
mozjemalloc_types.h	Bug 1376408 - Randomize free region selection for small allocations in a run r=glandium	2019-06-18 21:18:23 +00:00
mozjemalloc.cpp	Bug 1376408 - Randomize free region selection for small allocations in a run r=glandium	2019-06-18 21:18:23 +00:00
mozjemalloc.h
mozmemory_wrap.cpp	Bug 1559379 - Export C++ allocation functions from mozglue on all platforms. r=froydnj	2019-06-27 22:07:42 +00:00
mozmemory_wrap.h	Bug 1559379 - Export C++ allocation functions from mozglue on all platforms. r=froydnj	2019-06-27 22:07:42 +00:00
mozmemory.h
Mutex.h
rb.h
replace_malloc_bridge.h
replace_malloc.h
Utils.h
zone.c