This is the mail archive of the 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: malloc: performance improvements and bugfixes

On 01/25/2016 07:24 PM, Joern Engel wrote:
> From: Joern Engel <>
> Short version:
> We have forked libc malloc and added a bunch of patches on top.  Some
> patches help performance, some fix bugs, many just change the code to
> my personal liking.  Here is a braindump that is _not_ intended to be
> merged, at least not as-is.  But individual bits could and should get
> extracted.

You certainly have done quite a bit of work to tune glibc's general
purpose allocator into something that specifically suits your application
needs. Thank you for sharing the high-level details of your changes.

I appreciate your posting of these patches to the mailing list, they are
certainly a very interesting (even if I can't read them beyond their
general description, and I wish I could).

I would like to respond formally, as an GNU project steward for the GNU
C Library project to the top of this thread and make two points very
clear (not buried in another thread):

(1) The GNU C Library project, as a GNU project, requires copyright 
    assignment for legally significant changes by a particular author.

    This requirement is linked to here: "contribution checklist":

    See the "FSF copyright assignment":

    If you have any questions, please reach out directly to the FSF.

    Even though you never intended to submit these patches for inclusion,
    as you say in your email, you stand to taint anyone who reads these
    changes and then tries to implement similar work. This is nothing new,
    we face this challenge every day, but it bears repeating and you
    present the perfect opportunity to reiterate this message.

(2) Objective performance evaluations.

    We take microbenchmarking and whole-system benchmarking very seriously
    and any changes presented by anyone, senior or junior, should provide
    methods of objective evaluation of performance.

While I know you did not intend your posts to be considered for
formal inclusion, it is still a good time to point out the above
two important criteria. This way others watching don't wonder why
we didn't simply include your patches directly into glibc master
with some minor cleanups.

>From patch inception to commit there is always a lot of work to
do for a core project like glibc.

I hope and look forward to your future submissions to the project.


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