GNU bug report logs - #45200
Wishlist: There should be a `malloc-trim' function

Previous Next

Full log

View this message in rfc822 format

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 45200 <at> debbugs.gnu.org
Subject: bug#45200: Memory leaks: (garbage-collect) fails to reclaim memory
Date: Sun, 24 Jan 2021 22:00:31 +0300

On Sun, 2021-01-24 at 13:51 -0500, Stefan Monnier wrote:
> > # Steps to reproduce:
> > 
> > 1. Run `mkdir /tmp/.emacs.d`
> > 2. Run emacs as `HOME=/tmp/ emacs`, and measure its PSS
> > 3. Create a file /tmp/.emacs.d/early-init.el with content:
> > 
> >     ;; only run garbage collection on idle
> >     (setq gc-cons-threshold most-positive-fixnum)
> >     (run-with-idle-timer 2 t (lambda () (garbage-collect)))
> > 
> > 4. Run emacs as `HOME=/tmp/ emacs`, evaluate (garbage-collect), then measure
> > its PSS
> > 
> > ## Expected
> > 
> > Size has no statistically-significant difference, because in both
> > cases we garbage-collected memory.
> 
> I disagree with this expectation: it is perfectly normal for the amount
> of memory allocated to the Emacs process to be left higher if you delay
> the GC.  There are various reasons for that:
> - fragmentation, of course.  Not much we can do about it short of using
>   a moving collector.
> - the desire to keep memory around rather than return it to the OS,
>   under the assumption that we'll need it again soon.
> 
> And it's not considered as a memory leak as long as that memory has
> indeed been needed in the past and that future allocations can still
> make use of it.

I'm fine with Emacs possibly keeping a dozen of megabytes for personal use. The problem though is that the issue easily manifests itself in hundreds of megabytes, as can be seen with the testcase marked as "Message #11" in web-ui.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.