* [gentoo-dev] Evaluating a new malloc()
@ 2013-02-26 13:33 99% Richard Yao
0 siblings, 0 replies; 1+ results
From: Richard Yao @ 2013-02-26 13:33 UTC (permalink / raw
To: gentoo-dev@lists.gentoo.org
[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]
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?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2013-02-26 13:33 99% [gentoo-dev] Evaluating a new malloc() Richard Yao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox