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: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Tue, 26 Jan 2016 22:57:31 +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> <56A7EA47 dot 1000908 at cs dot ucla dot edu>
On 01/26/2016 10:51 PM, Paul Eggert wrote:
> On 01/26/2016 01:40 PM, Florian Weimer wrote:
>> In short, things aren't as bad as we thought they are, and we can
>> finally fix bug 6527 after we have implemented the traversal of the
>> dumped heap I mentioned above.
>
> Thanks for the heads-up. We have also circulated some changes on the
> Emacs side, to help Emacs work better with the Cygwin port of glibc,
> which also has problems in this area. These Emacs changes are not yet
> installed and are not currently planned for the next Emacs release, but
> are likely to go in after that. When it's convenient I would like to
> test these Emacs changes with the glibc malloc changes that you're
> envisioning, and iron out any glitches that come up.
One change you can make *today* is to include <malloc.h> in src/emacs.c
(conditionally for dlmalloc), and not just the autoconf test case. This
way, you will actually see new deprecation warnings as they appear in
the header file.
You won't get one for __malloc_initialize_hook, even though it's been
deprecated for close to five years now. This is because GCC does not
warn if you supply a definition for a deprecated declaration, and
__malloc_initialize_hook is used through symbol interposition (because
any assignment would happen too late).
Florian