This is the mail archive of the
libc-alpha@sourceware.org
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
> malloc.
>
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/