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 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.
> 
> jeff

For hooks I tried to write alternative implementation.

https://www.sourceware.org/ml/libc-alpha/2013-11/msg00207.html

I think that hooks should come in separate library that is independent
on allocator.

>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.


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