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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: 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>, wg at malloc dot de
- Date: Tue, 10 Dec 2013 09:05:35 +0100
- Subject: Re: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com> <52A6BBE7 dot 5050105 at suse dot com> <20131210074801 dot GG5048 at spoyarek dot pnq dot redhat dot com>
On 12/10/2013 08:48 AM, Siddhesh Poyarekar wrote:
> On Tue, Dec 10, 2013 at 07:59:51AM +0100, Andreas Jaeger wrote:
>> 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,
>
> From a quick look through ptmalloc3, I don't think merging ptmalloc3
> changes is going to be any easier before making any changes to our
> malloc. Our code base seems to have diverged enough (with multiple
> arenas, per-thread arenas, dynamic thresholds, hooks, probes, etc.) to
> make it very different from ptmalloc. I definitely see merit in
> looking for stuff in ptmalloc3 that we can use, but given the current
> complexity of that task, I don't think it makes sense to have it hold
> up cleanups.
Thanks for the evaluation - in that case, let's do cleanups ;)
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