This is the mail archive of the
mailing list for the glibc project.
Re: The direction of malloc?
- From: Will Newton <will dot newton at linaro dot org>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Andreas Jaeger <aj at suse dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andreas Schwab <schwab at suse dot de>, Ondřej Bílka <neleai at seznam dot cz>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Tue, 10 Dec 2013 10:42:54 +0000
- Subject: Re: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com>
On 10 December 2013 05:04, Carlos O'Donell <firstname.lastname@example.org> wrote:
> For a long time we have refused patches to malloc because they would
> change the formatting of the code and make it difficult to ... I can
> only assume... synchronize with the rapid upstream development of
> It is my opinion that glibc should forge ahead on a new direction for
> malloc. We should accept any such patches that would:
> * Make it easier for us to maintain the malloc implementation.
> - Removing dead code.
> - Simplifying macros.
> - Removing features we don't use.
> * Add new and required features.
> - Add support for "have but don't need" kernel pages via vrange.
> * Fix bugs.
> We should accept these patches without the restrictions we previously
> placed on the malloc implementation. We should use GNU formatting to
> make the code match all of our other styles. In effect we should
> own the copy of ptmalloc2 we started with and change it into the
> implementation that we think our users need.
I think this is a sound approach. As far as I can tell the glibc
malloc has diverged significantly from ptmalloc2 to the point of
making changes hard to merge and we shouldn't let this stop us from
making incremental improvements to what we have. Also the glibc code
is by definition much more widely tested than any specific version of
ptmalloc or dlmalloc I think.
There is ptmalloc3 but I suspect the upheaval of merging that would be
equivalent to switching to any other 3rd party allocator and there are
much more advanced allocators available these days.
> I even encourage the discussion of providing alternate allocators
> like jemalloc.
I have been looking into this and also developing my own allocator
code. Unfortunately it is still at an early stage and not
fast/featureful/stable enough yet. jemalloc is a really good allocator
and provides excellent performance and profiling features, I had
assumed the licensing would be an issue for integration into glibc
One of the things I really need to get into shape is some kind of
benchmarking for malloc, including some simple micro-benchmarks and
some applications that can be used to test allocator performance. I
would not like to embark on integrating a new allocator without some
really solid benchmarks in place.
Toolchain Working Group, Linaro