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: Indentation and gc Date: Sat, 11 Mar 2023 15:08:23 +0200 Message-ID: <83ilf7wi48.fsf@gnu.org> References: <20230310110747.4hytasakomvdyf7i.ref@Ergus> <20230310110747.4hytasakomvdyf7i@Ergus> <87a60k657y.fsf@web.de> <838rg4zmg9.fsf@gnu.org> <87ttys4dge.fsf@web.de> <83sfebyepp.fsf@gnu.org> <87ttyru4zt.fsf@web.de> <83fsabyb41.fsf@gnu.org> <87mt4jtpqf.fsf@web.de> 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="6260"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, emacs-devel@gnu.org To: "Dr. Arne Babenhauserheide" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 11 14:09:07 2023 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 1payyA-0001TU-UM for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Mar 2023 14:09:07 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1payxm-0002UE-26; Sat, 11 Mar 2023 08:08:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1payxk-0002U4-O3 for emacs-devel@gnu.org; Sat, 11 Mar 2023 08:08:40 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1payxk-0002UB-CD; Sat, 11 Mar 2023 08:08:40 -0500 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=na0/R5a9ctyVE98HG5fvamzuIoAh7qfnfunGI0ujzKA=; b=SgmX92et+/bLjUQX/LYl a0QZoT4BOI+9+U1NtGXzTOYP83nhj0AwHMGg/VO3ug0j7bHAmJiboWg3ffxhlBaR6I3I0OPD8YCBL wAhVD2C2WZDBFhqlpZlKcduSDJR1KXz9Lkkv1ijHEV9nBZuFbIDrpq525z/EXHkQUuu/ansvGoBaS IW25Sf3HbFBQE+nRoJGRBJuEVqKSWNtkgVcBuuM1TviJ2tujJSa85cjei9ye8mB0Qr32y8PXAkpQc 5KLiul80IlO48ESwkAwou5hMMRVHnYjeyC0sVAEFCTfu1QjMSiKJvZrEF3wZlo1OCVd9uineAvoC6 /0c2m7+nQms9/w==; Original-Received: from [87.69.77.57] (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 1payxj-0004ee-Gx; Sat, 11 Mar 2023 08:08:39 -0500 In-Reply-To: <87mt4jtpqf.fsf@web.de> (arne_bab@web.de) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304306 Archived-At: > From: "Dr. Arne Babenhauserheide" > Cc: spacibba@aol.com, emacs-devel@gnu.org > Date: Sat, 11 Mar 2023 13:34:54 +0100 > > > Perhaps the only thing we could do is enlarge the value slightly in > > Emacs 30. > > That could already help, yes. Maybe not by factor 25 as I did (that’s > mostly for lsp work), but just adjusting to how much the lower limit of > systems changed that can run Emacs 30. No, a factor of 25 is definitely too much. I'd say maybe 4 or 5. > > So raising the threshold indirectly raises the probability of having > > your system run out of memory, even if the threshold value is way > > below the amount of VM you have. > … > > See above: to what value will you enlarge it so that it's still safe? > > The Emacs startup typically does a lot of non-trivial stuff, so could > > consume large quantities of memory. > > With the main risk being that we could go OOM, could Emacs evaluate the > available memory on the system on systems that support that check? It can, but what would you want to do with that value? We cannot use it as the threshold, for the reasons I explained earlier. We could use some fraction of it, but what fraction? The answer depends on what other programs routinely run on that system. For example, if the user is likely to run another full-fledged session of Emacs (some people actually do that, e.g., to run Gnus in a separate process), then using 1/2 of the amount of VM as the threshold is out of the question, right? And there are memory-hogging programs out there which use much more than Emacs does. > If Emacs can give back memory to the OS (I expect that it can, but I am > not sure¹) It depends... In some situations (and some OSes), it doesn't. > ¹: Can Emacs give back memory to the OS? Depends on the implementation of malloc and on memory fragmentation.