This is the mail archive of the
mailing list for the glibc project.
Re: malloc: performance improvements and bugfixes
- From: Florian Weimer <fweimer at redhat dot com>
- To: munroesj at linux dot vnet dot ibm dot com
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, Joern Engel <joern at purestorage dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, Joern Engel <joern at purestorage dot org>
- Date: Tue, 26 Jan 2016 22:40:50 +0100
- Subject: Re: malloc: performance improvements and bugfixes
- Authentication-results: sourceware.org; auth=none
- References: <1453767942-19369-1-git-send-email-joern at purestorage dot com> <56A6C2E4 dot 7050508 at cs dot ucla dot edu> <1453841413 dot 18407 dot 7 dot camel at oc7878010663>
On 01/26/2016 09:50 PM, Steven Munroe wrote:
> So why not fix emacs to stop doing this (purely evil behavior).
> If they want to persist their internal state from session to session
> there are better ways. For example: https://sphde.github.io/
It's complicated, but not just for the technical challenges involved.
My warning to the Emacs developers that we are going to clean this up on
the glibc side was not universally well-received.
Some of the Emacs developers think they have a stop-gap solution for
future Emacs binaries: They are going to interpose their own malloc. My
testing agrees; it should happen automatically once we remove
long-deprecated symbols from <malloc.h> because that will cause their
autoconf check to fail, triggering a switch to their built-in malloc.
(This will happen even before with deprecate and eventually remove
__malloc_get_state and __malloc_set_state from the API.)
For existing binaries with newer glibc, I think I found a way to quickly
rewrite the dumped heap in such a way that we do not have to add any
special cases to the hot paths in free/realloc. (We don't even have to
use Siddhesh's corrupt arena code for that, although that could be an
option as well.) The main challenge is whether we can obtain the
address of the first *allocated* chunk on the main arena. Once we have
that, we can do the heap traversal. I expect maybe a few dozen lines of
code for this in total, and the constraints on future malloc evolution
are minimal. It's much better than maintaining two mallocs inside glibc.
I also know one reason why valgrind does not work with dumped Emacs
binaries, and it's quite straightforward to fix (it could easily be part
of the traversal to rewrite the heap, but we have to implement it twice,
once in glibc and once for the Emacs malloc implementation). Let's hope
this is the only fix needed to get valgrind going.
In short, things aren't as bad as we thought they are, and we can
finally fix bug 6527 after we have implemented the traversal of the
dumped heap I mentioned above.