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: Sat, 18 Jun 2022 16:20:24 +0300 Message-ID: <83a6aanm5j.fsf@gnu.org> References: <83bkuzznws.fsf@gnu.org> <877d5mqmkh.fsf@localhost> <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> 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="12336"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, yantar92@gmail.com, mattiase@acm.org, theophilusx@gmail.com, rms@gnu.org, acm@muc.de, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 18 15:22:26 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 1o2YPC-00031G-51 for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jun 2022 15:22:26 +0200 Original-Received: from localhost ([::1]:40272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2YPB-0002C0-4U for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jun 2022 09:22:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45108) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2YNS-0001LC-4e for emacs-devel@gnu.org; Sat, 18 Jun 2022 09:20:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35084) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2YNR-0003Fk-Ao; Sat, 18 Jun 2022 09:20:37 -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=GjdkkbmsDNp6vdJCNChugwTxWfU6tg8eWn0EhVqmld0=; b=ao/ml0pEgBEQUCZqim/3 L9+pNi2ivVvVwnHxxO+fiVlLyHQrkEcFzQB9FKIJEbAHmF7F60W13psvWlQUNSX6euZL7FtBpSF7Z PK2/BktUg9OgZc/vMaXwQ+l/+vJIL/FDzJxHZ0iO1/VpJZTEFlK3vEPU3s09wqyjtjGH+XCMTBAU/ Nboru4r19bQslgNiwYQPgJ6ydX0wFAyy+wyDhXiqlIRqidkMkk7164UV3dyubYxFF5rj3gUOPpnme F3qdZdFcxBhy6MezOCm9s4BgdUUnVpbmvt1wxIdlS+/LVxFAIeva1Nrq9eJDmmwIKaxV87n8CQIge 5k+fVZwDwl5WbQ==; Original-Received: from [87.69.77.57] (port=1979 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 1o2YNP-00013o-W2; Sat, 18 Jun 2022 09:20:36 -0400 In-Reply-To: <871qvm16he.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 18 Jun 2022 14:49:49 +0200) 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:291366 Archived-At: > From: Lars Ingebrigtsen > Cc: Ihor Radchenko , Mattias Engdegård > , Eli Zaretskii , Tim Cross > , rms@gnu.org, Alan Mackenzie , > emacs-devel > Date: Sat, 18 Jun 2022 14:49:49 +0200 > > Stefan Monnier writes: > > > Obviously this process ends up with a very large one-step allocation > > which is arguably interesting in itself (I suspect there's some > > GC-inhibition going on there), but the more interesting point > > is that with p=0.1 we get an amount of free space after GC > > (i.e. blocks we can't release, because of fragmentation) that's about as > > large as the next threshold, i.e. about 10%, whereas with p=1.0 this > > amount of unreleasable free space is significantly higher. > > As far as I know, we never actually release back cons space to the OS > anyway -- even if we could. (Because glibc's malloc implementation > doesn't do that unless we call that trim function, which we don't.) AFAIK, that's not really true. We call 'free' and glibc does release to the OS when it can. And don't forget that Emacs calls 'malloc' a lot not just for conses and other Lisp data.