This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: The direction of malloc?
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Will Newton <will dot newton at linaro dot org>
- 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>, OndÅej BÃlka <neleai at seznam dot cz>
- Date: Tue, 10 Dec 2013 16:40:32 +0530
- Subject: Re: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
- References: <52A6A0DA dot 1080109 at redhat dot com> <CANu=Dmi32gwk-hQ3dDbj0d4_gs3FWqt02+NmveXH1p03Vm+Mfg at mail dot gmail dot com>
On Tue, Dec 10, 2013 at 10:42:54AM +0000, Will Newton wrote:
> 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?
A really cool feature would be to have the ability to plug in malloc
implementations at least at build time in the beginning and then later
at runtime using tunables. It should be doable by implementing a
layer that passes calls on to the selected implementation. This would
have to be implemented using relocation (IFUNC?) since otherwise we're
introducing an additional cost.
> 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.
I assumed you had volunteered yourself for this ;)
Siddhesh