[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lost or corrupted `undo-tree' history

From: Alexander Shukaev
Subject: Re: Lost or corrupted `undo-tree' history
Date: Fri, 10 Jan 2020 10:19:15 +0100

On 1/10/20 9:07 AM, Eli Zaretskii wrote:
From: Alexander Shukaev <address@hidden>
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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]