From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Should use of mallopt depend on DOUG_LEA_MALLOC? Date: Sat, 14 Dec 2019 09:59:01 +0200 Message-ID: <83h82372yi.fsf@gnu.org> References: <87sgme1ww7.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83o8x0rl6d.fsf@gnu.org> <87lfs2mzo8.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <87lfs19shb.fsf@mail.linkov.net> <87a78gn5k5.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83sgm8ox3g.fsf@gnu.org> <87zhgflxmc.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83lfrzq1s1.fsf@gnu.org> <87d0d7w3tt.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83zhgaloc5.fsf@gnu.org> <87zhg7jmjg.fsf@yantar92-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83h82ej03y.fsf@gnu.org> <87r21ick48.fsf@gmail.com> <83immthovt.fsf@gnu.org> <87o8wkc50t.fsf@gmail.com> <83lfrodix4.fsf@gnu.org> <87immkctly.fsf_-_@gmail.com> <83tv6470ko.fsf@gnu.org> <4bd5ae89-2862-586f-7f77-cb469d12197e@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="239161"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, npostavs@gmail.com To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 14 08:59:19 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ig2Kd-00104z-Iu for ged-emacs-devel@m.gmane.org; Sat, 14 Dec 2019 08:59:19 +0100 Original-Received: from localhost ([::1]:57100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ig2Kb-0004U7-V2 for ged-emacs-devel@m.gmane.org; Sat, 14 Dec 2019 02:59:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49706) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ig2KW-0004U1-MN for emacs-devel@gnu.org; Sat, 14 Dec 2019 02:59:13 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ig2KV-0001BV-R8; Sat, 14 Dec 2019 02:59:11 -0500 Original-Received: from [176.228.60.248] (port=3914 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ig2KU-0000HY-By; Sat, 14 Dec 2019 02:59:11 -0500 In-reply-to: <4bd5ae89-2862-586f-7f77-cb469d12197e@cs.ucla.edu> (message from Paul Eggert on Fri, 13 Dec 2019 13:55:36 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243373 Archived-At: > Cc: Noam Postavsky , emacs-devel@gnu.org > From: Paul Eggert > Date: Fri, 13 Dec 2019 13:55:36 -0800 > > On 12/13/19 7:22 AM, Stefan Monnier wrote: > > For those in `init_alloc_once_for_pdumper`, I can't help you. > > Those mallopt calls shouldn't be needed. Can you elaborate why? And if that's indeed true, then what is our response to reports such as the one in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38345#71 ? I thought a judicious use of mallopt would allow us to come close to jemalloc, but if not, then what would? Assuming what Ihor Radchenko sees and is reported in that discussion is normal operation of glibc's malloc, don't we want to be able to return memory to the OS more eagerly than the default malloc configuration does? > Proposed patch attached. The basic idea is to use "#ifdef M_MMAP_MAX" > instead of "#ifdef DOUG_LEA_MALLOC" to decide whether to call mallopt > with M_MMAP_MAX. Plus, stop fiddling with mallopt parameters that are > problematic given that glibc malloc has mutated so much (and is likely > to mutate further). Thanks, but let's postpone such cleanups until after the release branch is cut (hopefully soon). I would like to leave the unexec-related code in its current form for Emacs 27.1, and only fix any bugs that will be reported against it.