|
From: | Paul Eggert |
Subject: | Re: Removal of unexec support from glibc malloc |
Date: | Mon, 18 Jan 2016 22:31:07 -0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
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=noThis 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.
[Prev in Thread] | Current Thread | [Next in Thread] |