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: 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[1].  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[2].

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.

[1] https://sourceware.org/glibc/wiki/Contribution%20checklist#FSF_copyright_Assignment
[2] https://pagure.io/glibc-malloc-trace-utils


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