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

[Sergei Trofimovich <slyfox@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

On Tue, 26 Feb 2013 08:33:44 -0500
Richard Yao <ryao@gentoo.org> 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.

Thre real disease is Windows support for all the mentioned apps.
glibc is not that bad.

I suspect
    export MALLOC_CHECK_=0
and
    CFLAGS=-fno-stack-protector
would solve all those bookkeeping "issues" glibc dumps on you
by default.

malloc() (likely free()) performance dependency for an app
means writing custom allocators. IMHO it's a per-app problem,
not system-wide one.

Do you have degradation example for your use cases? (a sample
program for real workload) Fixing known deficiencies is always
simpler than switching known-to-work base.

> 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 would not solve bundling problem, would it?

> Unless a significant issue is found in jemalloc itself, I do not see any
> reason to continue using glibc's ptmalloc over jemalloc.

How about "that core piece of libc works fine"?

-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]