From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Shukaev Newsgroups: gmane.emacs.devel Subject: Re: Lost or corrupted `undo-tree' history Date: Fri, 10 Jan 2020 10:19:15 +0100 Message-ID: <64a45342-251e-06b3-d836-6a0f19e3c114@Alexander.Shukaev.name> References: <1631cfa6-91e2-1fc9-85b8-fdb55a4aa765@Alexander.Shukaev.name> <835zhjag4g.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="44355"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 10 10:21:53 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.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 1ipqUA-0006ID-AE for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Jan 2020 10:21:42 +0100 Original-Received: from localhost ([::1]:42886 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipqU9-0006xE-0j for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Jan 2020 04:21:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36113) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ipqRx-0003FG-5n for emacs-devel@gnu.org; Fri, 10 Jan 2020 04:19:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ipqRv-0007r0-La for emacs-devel@gnu.org; Fri, 10 Jan 2020 04:19:24 -0500 Original-Received: from relay10.mail.gandi.net ([217.70.178.230]:41751) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ipqRt-0007XT-OE; Fri, 10 Jan 2020 04:19:21 -0500 Original-Received: from [192.168.0.110] (unknown [79.134.79.103]) (Authenticated sender: forum@alexander.shukaev.name) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 7971E24000E; Fri, 10 Jan 2020 09:19:16 +0000 (UTC) In-Reply-To: <835zhjag4g.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 217.70.178.230 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:244170 Archived-At: On 1/10/20 9:07 AM, Eli Zaretskii wrote: >> From: Alexander Shukaev >> Date: Wed, 8 Jan 2020 23:45:35 +0100 >> >> I believe the garbage collector can be temporarily disabled >> by simply wrapping the body of `undo-list-transfer-to-tree' into the >> following `let' form: >> >> (let ((gc-cons-threshold most-positive-fixnum)) >> ...) > > IMO, it would be a very bad mantra for a Lisp package operating on > this low level to disable GC, because that could cause the user's > system to run out of memory, and Emacs be killed by the likes of OOM > killer agents. Disabling GC is barely a good idea on the > user-customization level, certainly not in packages such as undo-tree. > Maybe. I was under impression that for a "short-running" function this might be fine to prevent GC from running in-between some Emacs Lisp instructions. Having said that, I agree that disabling GC sometimes may be dangerous practice. I remember how after reading [1], I tried that suggestion for minibuffer. After some time I noticed that I keep running out of memory. What was interesting is the actual test case. For example, I could run some search command which pushes matches into minibuffer, say up to 100 000 matches. As this is happening (and `gc-cons-threshold' is `most-positive-fixnum'), I can see memory consumption of Emacs growing rapidly say from 500MB up to 8GB at which point I cancel the search and exit the minibuffer command. As a result, `gc-cons-threshold' comes back to the default value and garbage collecting starts immediately. However, the memory consumption of Emacs does not fall back to 500MB, but rather goes down to only e.g. 6GB, which afterwards are never ever reclaimed. If I repeat the test, the memory consumption would immediately continue to grow off 6GB further as if those 6GB are not reused and are somehow stuck holding something that cannot be reclaimed anymore. Hence, you can see that if I way same amount of time, the memory consumption would go to around 14GB. This is how one can quickly run out of memory as if there would be some memory leaks related to GC. Now, I have no experience to say whether lower (e.g. default) values of `gc-cons-threshold' don't trigger memory leaks or they simply go unnoticed because the memory consumption grows very slowly. Since, theoretically, GC memory leak if present should be there regardless of `gc-cons-threshold'. Thoughts? Nevertheless, the second suggestion (for speeding up initialization code) from [1], IMO, is a good example of temporarily blowing `gc-cons-threshold' which I still use. [1] https://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/