On Tue, 26 Feb 2013 08:33:44 -0500 Richard Yao <[email protected]> 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
Description: PGP signature
