This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: malloc: performance improvements and bugfixes
- From: Florian Weimer <fweimer at redhat dot com>
- To: JÃrn Engel <joern at purestorage dot com>
- Cc: munroesj at linux dot vnet dot ibm dot com, Paul Eggert <eggert at cs dot ucla dot edu>, "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 23:02:37 +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> <56A7E7E2 dot 8090604 at redhat dot com> <20160126215951 dot GL5745 at Sligo dot logfs dot org>
On 01/26/2016 10:59 PM, Jörn Engel wrote:
> On Tue, Jan 26, 2016 at 10:40:50PM +0100, Florian Weimer wrote:
>> 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.
>
> One option is to do something like
>
> #define USE_NEW_MALLOC
> #include <stdlib.h>
This is not an option because we would have to prevent all libraries
which Emacs links against from doing this (recursively). This does not
work.
And we don't want to maintain two mallocs inside glibc.
Florian