This is the mail archive of the
mailing list for the glibc project.
Re: The direction of malloc?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Jeff Law <law 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>, Andreas Jaeger <aj at suse dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andreas Schwab <schwab at suse dot de>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Tue, 10 Dec 2013 10:45:26 +0100
- Subject: Re: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com> <52A6AC38 dot 6000008 at redhat dot com>
On Mon, Dec 09, 2013 at 10:52:56PM -0700, Jeff Law wrote:
> On 12/09/13 22:04, Carlos O'Donell wrote:
> >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.
> There was a time when those restrictions made some sense, I think
> that time has long past.
> >I even encourage the discussion of providing alternate allocators
> >like jemalloc.
> The one thing I was ping'd regularly about was the allocator from
> thread-building-blocks. Being able to use that without playing
> silly games would be useful.
> The other thing that I've been asked about a few times would be to
> fix the thread safety issues around the hooks, which IIRC requires
> some redesign.
For hooks I tried to write alternative implementation.
I think that hooks should come in separate library that is independent
>From time I wrote that I would do few improvements, one problem is that
free hooks could be called also to existing memory where malloc hook was
not called. This could be avoided by having custom destructor for free
and installing that.