Is jemalloc going to make its way into RELENG_6?

[Dan Nelson]

In the last episode (Oct 05), Vlad GALU said:
>     Judging from my tests (allocating numerous small objects, then
> freeing the memory) it looks like the bottleneck is in free(). I've
> built a different libc library with the malloc.c and tree.h taken
> from HEAD and it now behaves nicely. I haven't seen any bad side
> effects on this machine (it's the lappie I do most of my work on, I
> run KDE, seamonkey, mplayer, openoffice, the like) since I switched
> to the new libc. Another nice solution would be to ship the modified
> libc in base so the people who really need jemalloc can relink to it
> via libmap.conf.

You can compile just the -current version of malloc.c as a shared
object, then inject it into specific binaries:

$ gcc -O -Wall -I/usr/src/lib/libc/include -shared -o /lib/jemalloc.so jemalloc.c
$ MALLOC_OPTIONS=P date
date in malloc(): warning: unknown char in MALLOC_OPTIONS
Thu Oct  5 11:44:36 CDT 2006
$ LD_PRELOAD=/lib/jemalloc.so MALLOC_OPTIONS=P date |& head
Thu Oct  5 11:44:49 CDT 2006
___ Begin malloc statistics ___
Number of CPUs: 2
Number of arenas: 11
Chunk size: 524288 (2^19)
Quantum size: 16 (2^4)
Max small size: 512
Pointer size: 4
Assertions enabled
Allocated: 4096, space used: 1048576

I've tried this with seamonkey and mysqld, so this method seems to work
fine on complex apps.

-- 
	Dan Nelson
	dnelson at allantgroup.com