Re: Removal of unexec support from glibc malloc

[Paul Eggert <eggert at cs dot ucla dot edu>]

Florian Weimer wrote:
> See my other message.  I'm attaching the configure.ac patch I used.

Ah, in that case (as Joseph pointed out) in 2014 I mentioned a simple way to 
test this approach, which requires no patch to Emacs or to glibc. Configure 
Emacs this way:

./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>.

I'll test this more, and if it doesn't have problems then we can declare the 
issue resolved, from glibc's point of view anyway. On the Emacs side we still 
have unexec cleanup to do, but the glibc change does not make this much more 
urgent than it already is, and we needn't make any changes to Emacs before Emacs 
25 comes out.

> With a bit of luck, newer valgrind versions will even recognize the
> interposed malloc, simplifying leak detection.

Wow, thanks, I didn't know that.  I have been using valgrind only on temacs (the 
undumped, slow, and hard-to-use Emacs), because valgrind doesn't work on dumped 
emacs under GNU/Linux. With the above configuration hack, valgrind works on 
dumped emacs; this is a win when debugging, and to me it's worth the performance 
hit.