This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: The direction of malloc?
- From: Andreas Jaeger <aj at suse dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob 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>, wg at malloc dot de
- Date: Tue, 10 Dec 2013 07:59:51 +0100
- Subject: Re: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com>
On 12/10/2013 06:04 AM, Carlos O'Donell 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 even encourage the discussion of providing alternate allocators
> like jemalloc.
>
> Comments?
This was done in the past to sync with Doug Lea's malloc implementation.
Our malloc seems to be based on version 2.7 but 2.8.6 is current (see
http://gee.cs.oswego.edu/) - and Wolfram had a ptmalloc v3 on his
homepage (http://www.malloc.de/en/) that seems not to have been
integrated with glibc.
So, going to ptmalloc3 is an option to consider as well...
Since Wolfram seems not anymore interested with glibc (I've copied him
on this email so that he could chime in), we can just go forward.
Before changing the code massively, I suggest to discuss whether we stay
with ptmalloc2 or move to ptmalloc3. If we do the later, it might be
better to do the overhaul after the update.
Summing up: Yes, we own it and should adopt it - but let's not make our
life harder if possible,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 NÃrnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix ImendÃrffer,HRB16746 (AG NÃrnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126