Implicit malloc/free replacement on windows/MSVC

[Daniel Micay]

On 24/09/14 05:04 AM, David Rigby wrote:
> Hi,
> 
> 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 [1]) 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 [2], 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 [3].
> (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 [4].
> 
> 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…
> 
> 
> Thanks,
> 
> DaveR

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...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20140924/8bb93aac/attachment.sig>