The Blender project found some fairly remarkable discrepancies between what their software actually used and what glibc's ptmalloc allocated:
http://www.sintel.org/development/memory-jemalloc/ Results such as these led Blender and others (e.g. Chrome/Chromium, Firefox, Thunderbird) to bundle private versions of jemalloc. This bundling situation violates our policy against bundled libraries. The maintainers could just patch their software to link to libjemalloc. However, it might make more sense to evaluate jemalloc as a distribution-wide replacement for glibc's ptmalloc. It appears that run the following commands on amd64 to see how jemalloc works when used system-wide: echo dev-libs/jemalloc ~amd64 >> /etc/portage/package.accept_keywords emerge dev-libs/jemalloc echo /usr/lib64/libjemalloc.so.1 >> /etc/ld.so.preload I did this on my system, verified that jemalloc was being loaded with strace and rebooted. So far, sudo is broken and anything that is 32-bit will have the loader print an error about the library not being preloaded. On a related note, setuid binaries will obey /etc/ld.so.preload, even though they ignore LD_PRELOAD. There is a chance that patching jemalloc directly into glibc would solve the sudo issue, but I imagine that sudo is doing something strange, which likely merits attention. For now, I am using su as a substitute until I look into why sudo is broken. Unless a significant issue is found in jemalloc itself, I do not see any reason to continue using glibc's ptmalloc over jemalloc. As far as I know, FreeBSD, NetBSD, Facebook and others are using jemalloc, so I expect that no significant issues will be found. jemalloc will still needs testing before we can consider it. Doing good tests is hard, so I would like to crowd source ideas on the appropriate way to test a malloc implementation from the list. My expectation is that people on the list will collectively think of better ideas than I could on my own. With that said, what do people think?
signature.asc
Description: OpenPGP digital signature
