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

Previous Next

Package: emacs;

Reported by: Konstantin Kharlamov <hi-angel <at> yandex.ru>

Date: Sat, 12 Dec 2020 18:44:02 UTC

Severity: wishlist

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #62 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: Eli Zaretskii <eliz <at> gnu.org>, 45200 <at> debbugs.gnu.org
Subject: Re: bug#45200: Memory leaks: (garbage-collect) fails to reclaim memory
Date: Sun, 24 Jan 2021 16:41:04 -0500
> Why unrealistic? To me the situation is pretty clear: I needed 200M, but I don't
> need them anymore, so I want them released. What's unrealistic about that?

What can I say: it's not realistic and I already gave you two technical
reasons why that is.

> If that was your point about that "maybe the 200M of memory will be
> needed again", then as I said, yeah, maybe, maybe not — unless Glibc
> has a prophet module built-in, it can't know, so it should not behave
> as if it does.

Maybe so.  But to the extent that you consciously decided it's OK for
Emacs to use 200MB at time-step A, then you basically lost the "moral
authority" to say that it's not OK for Emacs to still uses up 200MB at
time-step B.

If you can show a similar excessive use of memory without doing
something like (setq gc-cons-threshold most-positive-fixnum), the
question becomes quite different.


        Stefan





This bug report was last modified 3 years and 78 days ago.

Previous Next


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