Re: [gentoo-dev] Evaluating a new malloc()

[Alec Warner]

On Tue, Feb 26, 2013 at 5:33 AM, Richard Yao <ryao@g.o> wrote:
> 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.

So I'm confused a bit. The glibc malloc does perform poorly in some
edge cases. Lots of folks use an optimized allocator. That doesn't
mean that the glibc one is necessarily bad or worth replacing.

In terms of 'following Gentoo policy.' We encourage packages to be as
close to upstream as possible. I cannot fathom why when you basically
find a performance bug in malloc, you start a thread on the list about
replacing it; as opposed to filing a bug against glibc or emailing the
glibc lists and asking them about it.

>
> 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

Well certainly we would never deploy an ld preload hack. If you want
to test jemalloc, why don't you actually recompile the system against
libjemalloc (patched glibc)?

>
> 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?
>

I see a *HUGE* reason. glibc ships with ptmalloc. If you think they
should use jemalloc, talk to them. Don't just do it in Gentoo.