Implicit malloc/free replacement on windows/MSVC
danielmicay at gmail.com
Wed Sep 24 16:14:33 PDT 2014
On 24/09/14 05:04 AM, David Rigby wrote:
> I’m investigating replacing our application's existing memory allocator (tcmalloc) with jemalloc, mainly due to jemalloc’s “lowest possible address” policy which facilities some application-level reallocation of long-lived objects to reduce heap fragmentation.
> The integration on Linux and OS X is working nicely, however I’ve come to Windows and I’ve hit a bit of an impasse in dealing with indirect uses of malloc (e.g. strdup()), and I wonder if anyone has any ideas.
> First - what does work:
> 1) I can build jemalloc as a DLL and using a deffile (inspired by mozilla ) I can create malloc/calloc/realloc/free symbols pointing at their je_ prefix’d equivalents (inside jemalloc.dll) which my application will use when explicitly calling those functions - so far so good.
> However, if the allocation indirectly calls malloc (for example via strdup()) then strdup uses the malloc symbol inside the CRT, and as soon as free() is called I get a segfault (not withstanding I also have two heaps in use now).
> 2) Going down the statically-linked route , I can create a jemalloc_s.lib which has a null JE_PREFIX, and hence the application itself will again call jemalloc’s malloc/free functions. But again the strdup problem remains.
> The only solutions I can find to this are either:
> (A) runtime-patching the various CRT functions to jump to the custom allocators versions - as implemented by tcmalloc .
> (B) building a custom version of the CRT with the memory allocation functions removed, and statically linking this into the application - as implemented by mozilla .
> Does anyone know of a “third way” to solve this?
> If not, I think the tcmalloc runtime-patching is fractionally the lesser of the two evils - would the list (Jason?) consider accepting a patch which ported that functionality to jemalloc? It’s written in C++ which may be undesirable, but it’s Windows only at least…
AFAIK it will work if you statically link jemalloc, then the CRT, and
don't have any dynamic libraries using the CRT. It would be fantastic if
there was a general solution implemented in jemalloc.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the jemalloc-discuss