annulen at yandex.ru
Mon May 18 12:20:16 PDT 2015
18.05.2015, 19:30, "Mayank Kumar (mayankum)" <mayankum at cisco.com>:
> Hi All
> My application worked perfectly with LD_PRELOAD and the virtual memory growth was contained. As soon as I linked it dynamically with jemalloc, this wasn’t the case. So virtual memory kept growing. So I am guessing that my application is still not using jemalloc but libc’s default malloc when linking dynamically. My application is a binary which links to many dynamically loadable libraries some of which are internally built and some are open source versions which we don’t always build. My questions are:-
> 1. When linking dynamically with jemalloc, is it a requirement to have –ljemalloc as early as possible or possibly the first library being linked to, to override the default malloc ?
Yes - this is how dynamic linking works on ELF platforms. When linker sees undefined symbol "malloc" it will take it from first ELF object (in order of specified ld arguments) which has defined "malloc" symbol.
> 2. What method does jemalloc uses while linking to override malloc, does it use the malloc_hooks to override or just the normal linking, so that whatever the linker gets first, it will link to .
LD_PRELOAD deals only with ELF linking, injecting your library(ies) in the beginning of *.so list used by runtime linked (e.g., ld-linux.so)
> 3. Would linking statically solve this issue, although my preference would be to link dynamically since I have at least 10 processes which needs jemalloc, and at least they would share the code in memory.
> 4. When linking with external open source libraries, do I need to re-compile those with jemalloc as well to make sure any mallocs in those libraries also go through jemalloc or that is not required. I am guessing it should not be required as long as my process links to the right malloc library, their dependencies should be correctly resolved.
More information about the jemalloc-discuss