On Thu, Mar 26, 2009 at 6:05 PM, Branko Čibej <[email protected]> wrote: > Paul Querna wrote: >>> FreeBSD 7.1-STABLE (amd opterons; people.apache.org): >>> APR 1.3: 242582048 >>> APR 2.0: 537562071 (+221%) >>> >> >> >> Same FreeBSD 7.1 machine, using tcmalloc[1] >> APR 1.3: 243307182 >> APR 2.0: 214131712 (-22%) >> >> I think we should consider bundling tcmalloc, or making it a compile >> time option. >> > > For some systems, TCMalloc may not work correctly on with > applications that aren't linked against libpthread.so (or the > equivalent on your OS). It should work on Linux using glibc 2.3, but > other OS/libc combinations have not been tested. > > *shudder* > > and: > > Don't try to load TCMalloc into a running binary (e.g., using JNI in > Java programs). The binary will have allocated some objects using > the system malloc, and may try to pass them to TCMalloc for > deallocation. TCMalloc will not be able to handle such objects. > > We have JNI bindings for Subversion, which uses APR, whose packaging and > compilation options we don't control. *boom*
That is only talking about loading tcmalloc using the normal library. you can compile tcmalloc to not use the malloc symbol -- APR would have to compile it with different symbol names if we were to bundle it.
