This is the mail archive of the
mailing list for the glibc project.
Re: malloc: performance improvements and bugfixes
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: 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 14:50:13 -0600
- 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>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Mon, 2016-01-25 at 16:50 -0800, Paul Eggert wrote:
> Thanks for doing all the work and bringing it to our attention. A couple
> of comments on the process:
> On 01/25/2016 04:24 PM, Joern Engel wrote:
> > I happen to prefer the kernel coding style over GNU coding style.
> Nevertheless, let's keep the GNU coding style for glibc. In some places
> the existing code doesn't conform to that style but that can be fixed as
> we go.
> > 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
> This underestimates Emacs. :-)
> Emacs "knows" so much about glibc malloc's internal data structures that
> Emacs should do the right thing if glibc removes the hooks in question.
> Of course we should test the resulting combination. However, the point
> is that Emacs's usage of glibc malloc internals shouldn't ossify glibc
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/