From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Larger GC thresholds for non-interactive Emacs Date: Thu, 23 Jun 2022 10:09:00 +0300 Message-ID: <8335fvg8kz.fsf@gnu.org> References: <83y1y2utnd.fsf@gnu.org> <87r13up587.fsf@localhost> <83o7yyur0l.fsf@gnu.org> <87leu2p3nu.fsf@localhost> <83leu2uewn.fsf@gnu.org> <87r13qv701.fsf@localhost> <83bkuursya.fsf@gnu.org> <87h74l9jk8.fsf@localhost> <83bkutqb3z.fsf@gnu.org> <9778F176-E724-4E61-B0FB-327BCDD316C0@acm.org> <87sfo4epeo.fsf@localhost> <87bkurrc5e.fsf@localhost> <87bkur72b7.fsf@gnus.org> <874k0j40e7.fsf@gnus.org> <871qvm16he.fsf@gnus.org> <83a6aanm5j.fsf@gnu.org> <87o7yozzj0.fsf@gnus.org> <83k098kg6c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25036"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, yantar92@gmail.com, mattiase@acm.org, theophilusx@gmail.com, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 23 09:10:53 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o4GzN-0006JG-5m for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 09:10:53 +0200 Original-Received: from localhost ([::1]:35912 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4GzK-0006Xk-Qt for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Jun 2022 03:10:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47232) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Gxp-0005os-BV for emacs-devel@gnu.org; Thu, 23 Jun 2022 03:09:19 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36196) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Gxn-00007z-62; Thu, 23 Jun 2022 03:09:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=A0wj9Q3Yv/C6C0AJMKWqPfySnMujZCIy+lCtm3ISt7s=; b=RHvvG4ylk9pGiZ38b7mS ruZ99LfmV0P8vhoRhaBc/Q8VQk7fhjQDN3+FBGSj95Ntttws40ktUi4p8cHa3fBtM1ncbF0Yt+bAz t2rischXaGt3gE3lVeIYg28esmawbe8y347EeQC/z93HfR6cVoszyhRSeMcYEoONPeUq7hbOshQFd 85xZKXzynx6lPvE8A90ud+18OYzAne+++lItL9AWMFDoMdToOFDHsBnw8Qmiw8fhDHX2PlCL0laZI JaWJgMyb1HYgvaQfebLR2LluZ9JYTkybyIt2R2BbK2IetWjafPwRDwLFpOcjpEikVMVMGKQpoUSIL NzN88IWNXK/nlA==; Original-Received: from [87.69.77.57] (port=1781 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4Gxh-0007Yq-9W; Thu, 23 Jun 2022 03:09:09 -0400 In-Reply-To: (message from Lynn Winebarger on Wed, 22 Jun 2022 19:30:20 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291525 Archived-At: > From: Lynn Winebarger > Date: Wed, 22 Jun 2022 19:30:20 -0400 > Cc: Lars Ingebrigtsen , Stefan Monnier , > Ihor Radchenko , Mattias Engdegård , > Tim Cross , rms@gnu.org, Alan Mackenzie , > emacs-devel > > > I can't tell what (if any) option allows me to overrule the configure > > scripts decision to use sbrk instead of mmap. > > You don't want that, not on GNU/Linux systems. We switched away of > sbrk and mmap for several good reasons. > > Not that I don't enjoy trawling through old threads in the emacs-devel archive > (searching for mmap led to a thread from the introduction of the portable dumper), > but it would be a lot easier if there were design notes somewhere recording > the rationale of the decisions reflected in the current code. We lack someone in the role of the "project historian", who would then summarize and publish the design discussions in the form of such notes. Volunteers are most welcome. > The best I can do now > is comb through the arguments on the list (and maybe in the bug tracker?) and > try to guess which points ended up getting reflected in the code. A better method is to use Git logs to find when the GNU/Linux build stopped using mmap, and then search the archives around that time. > I will say jemalloc appears to have a lot of heap profiling bells and whistles. AFAIU, so does glibc. Some of them where mentioned in the discussions you already unearthed, AFAIR.