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: Eli Zaretskii <eliz at gnu dot org>
- To: Wolfgang Jenkner <wjenkner at inode dot at>
- Cc: eggert at cs dot ucla dot edu, fweimer at redhat dot com, Emacs-devel at gnu dot org, libc-alpha at sourceware dot org
- Date: Tue, 19 Jan 2016 18:58:07 +0200
- 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> <85oachlmx2 dot fsf at iznogoud dot viz>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: Wolfgang Jenkner <wjenkner@inode.at>
> Cc: Florian Weimer <fweimer@redhat.com>, Eli Zaretskii <eliz@gnu.org>, Emacs-devel@gnu.org, GNU C Library <libc-alpha@sourceware.org>
> Date: Tue, 19 Jan 2016 14:27:21 +0100
>
> 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
Performance problems of ralloc.c is the least of our problems. The
real problem is that it relocates buffer text in memory when it thinks
that will allow it to coalesce small chunks of free memory into larger
chunks. The result is subtle problems in Emacs's C code that holds C
pointers to buffer text, notably when GC strikes, but also when a
large memory allocation is requested or freed. Some of these problems
are impossible or impractical to fix. When these bugs happen, they
are evasive and very hard to debug.
For that reason, we made a significant effort in the last years to get
rid of ralloc.c on as many systems as we can. Going back to using
ralloc.c more widely is really a non-starter, particularly considering
the fact that today's Emacs hackers are less proficient with C than
the (diminishing number of) old-timers, and will probably bump into
these problems much more easily.
So I really hope that the alternative of using gmalloc.c does NOT also
mean using ralloc.c on glibc-based platforms.
Using mmap is also not an attractive alternative, due to performance
problems as mentioned above.