[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Evaluating a new malloc()
From:       Sergei Trofimovich <slyfox () gentoo ! org>
Date:       2013-02-27 20:26:02
Message-ID: 20130227232602.3de39b88 () sf
[Download RAW message or body]


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

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]