This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Removal of unexec support from glibc malloc
- From: Wolfgang Jenkner <wjenkner at inode dot at>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Florian Weimer <fweimer at redhat dot com>, Eli Zaretskii <eliz at gnu dot org>, Emacs-devel at gnu dot org, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 19 Jan 2016 14:27:21 +0100
- Subject: Re: Removal of unexec support from glibc malloc
- Authentication-results: sourceware.org; auth=none
- References: <569CDB81 dot 6040600 at redhat dot com> <569D3BE0 dot 6050103 at cs dot ucla dot edu> <m2a8o2vg5x dot fsf at newartisans dot com> <569D4207 dot 4060209 at cs dot ucla dot edu> <83mvs2d5b2 dot fsf at gnu dot org> <858u3meiv1 dot fsf at iznogoud dot viz> <569D6A3E dot 2010009 at cs dot ucla dot edu> <569D73D7 dot 1080206 at redhat dot com> <569DD82B dot 20201 at cs dot ucla dot edu>
On Mon, Jan 18 2016, Paul Eggert wrote:
> ./configure emacs_cv_var_doug_lea_malloc=no
>
> This causes Emacs to use its own malloc implementation. Back then
> I observed that this hurt performance somewhat (text 0.5% larger, data
> 7.6% larger, 14% more CPU time on my usual benchmark) but I did not
> observe any bugs; see
> <https://lists.gnu.org/archive/html/emacs-devel/2014-02/msg00542.html>.
IIUC, this means that either mmap or src/ralloc.c is needed for memory
reallocations, and those do have very annoying performance problems in
non-contrived cases, please see bug#19393 for such a scenario.
The discussion about the performance problem begins at
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19393#46