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
View this message in rfc822 format
> From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
> Cc: 45200 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Tue, 26 Jan 2021 01:28:01 +0300
>
> On Mon, 2021-01-25 at 17:17 -0500, DJ Delorie wrote:
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > > Thanks, but is it really a good idea to call malloc_trim each time we
> > > free some chunk of memory?
> >
> > malloc_trim() is very expensive relative to free(), partly because of
> > what it needs to do, and partly because it flushes the fastbins cache.
> > If you call it every, say, 1000 iterations of free, that might suffice.
> > Or perhaps after each GC run.
>
> (un-ccing Glibc maintainers as this question is Emacs-specific)
Please don't, I invited them to these discussions because they can
help us make the right decisions.
> After a GC run, would that be at the end of `garbage_collect` function as Stefan
> mentioned?
That'd be easy to implement, but I'm not yet sure it's the best
alternative. In particular, I'd like to have some idea regarding how
much time such a call could take. In some usage patterns Emacs calls
GC very frequently, which slows down command execution and makes Emacs
less responsive. So much so that some people raise the GC threshold
too high trying to avoid this slowdown, and raising the threshold too
much is generally not a good idea. I don't want us to slow GC down
even more so that more people would shoot themselves in the foot by
raising the threshold.
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.