[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removal of unexec support from glibc malloc

From: Eli Zaretskii
Subject: Re: Removal of unexec support from glibc malloc
Date: Tue, 19 Jan 2016 18:58:07 +0200

> From: Wolfgang Jenkner <address@hidden>
> Cc: Florian Weimer <address@hidden>,  Eli Zaretskii <address@hidden>,  
> address@hidden,  GNU C Library <address@hidden>
> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]