malloc: performance improvements and bugfixes
Steven Munroe
munroesj@linux.vnet.ibm.com
Tue Jan 26 20:50:00 GMT 2016
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/
More information about the Libc-alpha
mailing list