Re: malloc: performance improvements and bugfixes

[Torvald Riegel <triegel at redhat dot com>]

On Mon, 2016-01-25 at 16:23 -0800, Joern Engel wrote:
> From: Joern Engel <joern@purestorage.org>
> 
> 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.
> 
> Long version:
> When upgrading glibc from 2.13 to a newer version, we started hitting
> OOM bugs.  These were caused by enabling PER_THREAD on newer versions.
> We split malloc-2.13 from our previous libc and used that instead.
> The beginning of a fork.
> 
> Later we found various other problems.  Since we now owned the code,
> we made use of it.  Overall our version is roughly on-par with
> jemalloc while libc malloc gets replaced by most projects that care
> about performance and use multithreading.

Could you describe the workloads you used to select / validate these
changes?  While several of the items you listed might be generally
useful, others are certainly workload-specific, at least as far as
choices regarding trade-offs are concerned.

> And maybe as a closing note, I believe there are some applications that
> have deeper knowledge about malloc-internal data structures than they
> should (*cough*emacs).  As a result it has become impossible to change
> the internals of malloc without breaking said applications and libc
> malloc has ossified.

I believe many people in the glibc community want to phase out these
ties to malloc internals, so that malloc can be improved for the vast
majority of users.