This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
The direction of malloc?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: 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>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Tue, 10 Dec 2013 00:04:26 -0500
- Subject: The direction of malloc?
- Authentication-results: sourceware.org; auth=none
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?
Cheers,
Carlos.