This is the mail archive of the
mailing list for the glibc project.
Re: Dynamic memory allocation primitives.
- From: DJ Delorie <dj at redhat dot com>
- To: Robin Miyagi <r dot miyagi at shaw dot ca>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 18 Apr 2019 21:27:27 -0400
- Subject: Re: Dynamic memory allocation primitives.
First off, thanks for working on stuff like this :-)
As a general comment, though, we really shouldn't even look at such a
large (based on the uuencoded size) contribution until you have a
copyright assignment in place. Also, since glibc's malloc is used in
so many places, a lot of benchmark data would be needed to justify such
a change - performance improvements in one app might be negated by
losses in other apps, for example. We have to be particularly careful
with glibc's malloc as it is the system default malloc in a lot of
distros. There are some malloc benchmarks in glibc, and I have some
workloads for the malloc simulator.
If the intention is to replace glibc's malloc, it would make more sense
to develop your code as a standalone malloc, like tcmalloc, jemalloc,
and supermalloc. That way it can get a lot of testing, benchmarking,
debugging, and use, before adding the task of putting it in glibc.