Using jemalloc with static link
colin at novocraft.com
Fri Jul 19 20:02:30 PDT 2013
I'll see if I can use your idea for dynamically linking. There's a few
libraries i would need to do this for but if I can sort this out it would
be good. At the moment I have statically linked releases for a few
different Linux builds.
With regard the is_malloc(je_malloc), I tried commenting out the #if &
#endif lines but the program still used glibc malloc, I guess this may be
order of loading the libraries so I will try with jemalloc first. I'll let
you know if that works.
Thanks for your advice and help.
On 20 July 2013 02:27, Jason Evans <jasone at canonware.com> wrote:
> On Jul 19, 2013, at 12:41 AM, Colin Hercus <colin at novocraft.com> wrote:
> > I am trying to test a HPC appl'n with jemalloc to see if it can reduce
> memory fragmentation and slow memory growth of a long running
> multi-threaded app.
> > This application is statically linked as it's not open source and we
> need one binary distribution to run on multiple Linux versions.
> > If I configure jemalloc without a jemalloc prefix (je_) and link with
> -static -ljemalloc I get linker errors for multiply defined symbols
> > g++ -m64 -Wl,--eh-frame-hdr -o ./bin/xxxx ./obj/xxxx.o ..... -static
> -pthread -lcrypto -lz -lbz2 -ldl -ljemalloc -lunwind
> There's a good chance that you can make the errors go away by putting
> -ljemalloc earlier in the link line. It looks to me like libcrypto is
> pulling in the glibc malloc symbols, and by the time the libjemalloc
> portion of linking occurs, it's too late for jemalloc to provide the
> symbols. That said, pure static linking is pretty perilous, and I
> recommend dynamically linking against the system libraries, and linking to
> static libraries by specifying e.g. libjemalloc_pic.a along with the .o
> object files (and/or .a archives) in your project. glibc in particular
> does an excellent job of maintaining symbol compatibility across many years
> of releases, so you can ship around a binary that is dynamically linked
> against glibc with fewer issues than you will run into with a statically
> linked-in glibc. glibc protects you from a rather unstable Linux kernel
> interface, and if you try to run your static binary on top of a
> substantially different kernel, hilarity will ensue.
> > If I build with a prefix of je_ then linking is okay but memory
> allocation is via glibc malloc. The same is true if I dynamically link
> without a prefix.
> > Is there any simple easy way to get je_malloc to hook itself in as a
> replacement for malloc the way tcmalloc does?
> jemalloc *does* hook itself in as a replacement for glibc malloc, but only
> if no prefix is specified. =) You can make a one line change to
> src/jemalloc.c to unconditionally enable hooking. Replace:
> #if ((is_malloc(je_malloc) == 1) && defined(__GLIBC__) &&
> #if 1
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jemalloc-discuss