This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: malloc: performance improvements and bugfixes
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: 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>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, Joern Engel <joern at purestorage dot org>
- Date: Wed, 27 Jan 2016 16:45:18 -0500
- 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>
On 01/25/2016 07:50 PM, 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.
Agreed. Paul, thank you for your contribution to make sure that
glibc and emacs empower the GNU ecosystem as best they can together.
Cheers,
Carlos.