GNU bug report logs -
#45200
Wishlist: There should be a `malloc-trim' function
Previous Next
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 #212 received at 45200 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> No. Even the tiniest allocation still in use at the top of the heap
>> locks the entire rest of the heap into memory.
>
> Hmm... then I don't understand: the user who reports the problem with
> Emacs claims that calling `malloc_trim` reduces the PSS size of
> Emacs tremendously (from 260MB down to 60MB).
>
> If `malloc_trim` can't release memory other than at the top, then how
> come glibc didn't recover those 200MB on its own (e.g. it seems 200MB
> is well beyond the default value of M_TRIM_THRESHOLD)?
Well, let me make up a case that "works" and you tell me if this is
common in emacs.
Consider you've spent the day doing normal things and your heap is at
100 Mb. Now you do something memory-intensive for a few minutes, and
stop, and gc runs. That "something" allocates a lot of memory, but it's
all going to be at the top of the heap - aside from whatever fits in the
first 100 Mb. It's all released, and GC free()'s it all. malloc_trim()
at this point would coalesce it and return it to the system.
As long as gc runs between each type of "task", a high-memory task will
be trimmable because GC would have freed all that memory and it's all
together at the top of the heap.
What would cause a problem is, say, if in the middle of running a high
memory task you *also* load a font or something and *that* locks the top
of the heap.
This bug report was last modified 3 years and 79 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.