From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.comp.lib.glibc.alpha,gmane.emacs.devel Subject: Re: Removal of unexec support from glibc malloc Date: Tue, 19 Jan 2016 18:58:07 +0200 Message-ID: <83si1tbj6o.fsf@gnu.org> 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> <569DD82B.20201@cs.ucla.edu> <85oachlmx2.fsf@iznogoud.viz> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453222699 22189 80.91.229.3 (19 Jan 2016 16:58:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jan 2016 16:58:19 +0000 (UTC) Cc: eggert@cs.ucla.edu, fweimer@redhat.com, Emacs-devel@gnu.org, libc-alpha@sourceware.org To: Wolfgang Jenkner Original-X-From: libc-alpha-return-66414-glibc-alpha=m.gmane.org@sourceware.org Tue Jan 19 17:58:14 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 1aLZbh-0002Xp-Mq for glibc-alpha@plane.gmane.org; Tue, 19 Jan 2016 17:58:14 +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:date:message-id:from:to:cc:in-reply-to:subject :reply-to:references; q=dns; s=default; b=jGrTwg3ZU1Mr4haXW2ntjS jG/rEryTdUv1qTWmt1XnrZ45wroD5b14NcX8ftAepV2T5E+xWpBDJaYQyapaYM3G XnvN5GYQiApF5Xoi61yETVDGm0EBUpQ9K0KjAGhZ0aXmlTtWXhRUuSZBOLOGrXz3 qXksvKnPbZIquzWn1tSdU= 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:date:message-id:from:to:cc:in-reply-to:subject :reply-to:references; s=default; bh=cbdCn1pjvSdcHgcf4MamEnGBRME=; b= el3vWgbi3DGh7JSqJvlfswOG1R7d7bZrw+DjvZLv/fWptYQ/OFkAXNJxx0AFgIKM 47c716DNLJ6PVetIuh5BGL+7W3I7A+sZ55tw7PukmwE9SJ+95fAI9IardayTv1To N9x1I2IAD2HOBH0YtUfVZGdBg3zJ4opBMrbMy1DTtM0= Original-Received: (qmail 28878 invoked by alias); 19 Jan 2016 16:58:08 -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 28860 invoked by uid 89); 19 Jan 2016 16:58:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=D*at, proficient, thinks, HTo:D*at X-HELO: eggs.gnu.org In-reply-to: <85oachlmx2.fsf@iznogoud.viz> (message from Wolfgang Jenkner on Tue, 19 Jan 2016 14:27:21 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e Xref: news.gmane.org gmane.comp.lib.glibc.alpha:58697 gmane.emacs.devel:198370 Archived-At: > From: Wolfgang Jenkner > Cc: Florian Weimer , Eli Zaretskii , Emacs-devel@gnu.org, GNU C Library > 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 > > . > > 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.