From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.comp.lib.glibc.alpha,gmane.emacs.devel Subject: Re: Removal of unexec support from glibc malloc Date: Mon, 18 Jan 2016 22:31:07 -0800 Message-ID: <569DD82B.20201@cs.ucla.edu> References: <569CDB81.6040600@redhat.com> <569D3BE0.6050103@cs.ucla.edu> <569D4207.4060209@cs.ucla.edu> <83mvs2d5b2.fsf@gnu.org> <858u3meiv1.fsf@iznogoud.viz> <569D6A3E.2010009@cs.ucla.edu> <569D73D7.1080206@redhat.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453185095 21404 80.91.229.3 (19 Jan 2016 06:31:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jan 2016 06:31:35 +0000 (UTC) Cc: Eli Zaretskii , Emacs-devel@gnu.org, GNU C Library To: Florian Weimer Original-X-From: libc-alpha-return-66403-glibc-alpha=m.gmane.org@sourceware.org Tue Jan 19 07:31:25 2016 Return-path: Envelope-to: glibc-alpha@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aLPp6-00032I-Cy for glibc-alpha@plane.gmane.org; Tue, 19 Jan 2016 07:31:24 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=vceerqZGuCjvAFvq tTMyzp1jnW0R+fcVyj46I12McEfExN6XDmDAbd5/zYQm9/xudU/ja4ZBSgw/O4E5 Xka9afG/LTWCqO1T6P/e18xXtugf0/yAbeuyQxBrCJ22DrnBorcPs/UJ56UixI0W MikhLHbnjRrU5d2d8/SvSQRZHLg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=AQqjvgokD4IkPOLER/e9DY uDgng=; b=Ye8jRIOxh0yFA9uhVuKqJXISSKM+HiloGH1EdohqVVG7c9iGDU0vy3 XV2IF7ysxzilxVWEPLWmT/kk9gQVns2Cs3u5OSOQzQ7FeThwC9P1VNvotOHUdxIO CnWBKGL9AR+uld+UUptWuA9Sg62Ev22fD+sjzjvVmeOaNiOhTWvmI= Original-Received: (qmail 104317 invoked by alias); 19 Jan 2016 06:31:14 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 104299 invoked by uid 89); 19 Jan 2016 06:31:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=76, Hx-languages-length:1426, urgent X-HELO: zimbra.cs.ucla.edu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <569D73D7.1080206@redhat.com> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:58686 gmane.emacs.devel:198340 Archived-At: 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 . 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.