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

Previous Next

Full log

Message #32 received at 45200 <at> debbugs.gnu.org (full text, mbox):

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

> # 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.

Eli wrote:
> Thanks, but is it really a good idea to call malloc_trim each time we
> free some chunk of memory?

I think if we want to call `malloc_trim`, the obvious place would be to
do it at the end of `garbage_collect`.


        Stefan

Previous Next

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