This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The direction of malloc?


On 10 December 2013 05:04, Carlos O'Donell <carlos@redhat.com> 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
> ptmalloc.
>
> 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
though?

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.

-- 
Will Newton
Toolchain Working Group, Linaro


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]