Linking everything with jemalloc at build time

[s_j_newbury]

I don't know if anybody else has tried this, but I've been emerging my systems lately with jemalloc linked in unconditionally, not using any LD_PRELOAD tricks.

I've achieved this through LIBS+="-Wl,-no-as-needed -ljemalloc -Wl,-as-needed" or LDFLAGS as needed. The reason for the no-as-needed/as-needed is otherwise the Gentoo system-wide default of "as-needed" results in jemalloc being dropped since glibc meets the symbol resolution requirements. Some packages had to be patched not to complain about using non-library flags in LIBS, this is a little contraversial since it's generally accepted that LIBS should only contain libraries, and LDFLAGS link flags, but the implementation of as-needed is per library, that is it applies to all following libraries on the link command line unless subsequently toggled, the only of doing this is to allow as-needed in LIBS (or add the lib to LDFLAGS).

The only real problem package is www-client/chromium which segfaults if you try this, so don't! Solution there would be to add jemalloc as a malloc option in the Chromium codebase since it already makes use of the malloc hooks internally.

World emerged this way results in a system with much better memory utililisation/performance characteristics than with the default glibc malloc. Well, that's what the Kool Aid tastes like anyway!

[kernelOfTruth]

Interesting approach !

I'm running chromium with explicitly disabled tcmalloc and ld_preload jemalloc,

so how's the performance or latency impact when running it on a system-wide basis ?

[Gatak]

Really nice! I've been using the LD_PRELOAD trick on things like Apache, php, etc with good effect. I'll try your method now instead

I haven't seen the use of "LIBS". What is the difference against using LDFLAGS?

[Ant P.]

I haven't seen the use of "LIBS". What is the difference against using LDFLAGS?

LDFLAGS and LIBS both get picked up automagically by GNU Makefile default rules, and anything that tries to be compatible. The LDFLAGS string is inserted before the source files and LIBS comes after them.

--as-needed and -l flags are actually position-sensitive, which is why this hack works.

[Gatak]

I see. Thanks. Anyone that can share some experience in using jemalloc systemwide? For now I have enabled it during compile of specific apps. Was thinking to use package.env in the future instead of force linking to jemalloc on all applications. Do all applications use malloc anyway?

[pqy330]

How about adding jemalloc to the dependency list of libc.so.6 by using patchelf --add-needed?
Because almost everything depends on libc.so.6, so everything depends on libjemalloc.so.

[Hu]

This thread is very old.

I recommend against modifying libc.so.6 in this way, for multiple reasons.

• Almost everything depends on libc.so. If you break libc.so, you will have very little use of your system until it is repaired. In particular, patchelf needs libc.so, so you cannot use patchelf to repair a broken libc.so. Restoring from a backup would be the simplest recovery path, assuming a valid backup exists.
• libjemalloc.so probably depends on libc.so, so introducing a dependency in the other direction might cause problems. I have not verified whether this breaks.
• jemalloc development has ceased, so if it does not work for you as-is, you may not get any upstream help.

[stefan11111]

Does jemalloc replace the system malloc, it doesn't use it's own symbols?
What about tcmalloc?

I know palemoon uses jemalloc to speed up allocations. What is the impact of using a different allocator system-wide like this?