[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45200: [PATCH] Force Glibc to free the memory freed
From: |
Konstantin Kharlamov |
Subject: |
bug#45200: [PATCH] Force Glibc to free the memory freed |
Date: |
Tue, 26 Jan 2021 18:02:06 +0300 |
User-agent: |
Evolution 3.38.3 |
On Tue, 2021-01-26 at 16:55 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: 45200@debbugs.gnu.org, monnier@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@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.
Sorry, okay.
> > 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.
Yeah, that's true, there's an existing advice to make GC only run on idle.
Which is the reason btw this bugreport eventually came to life ☺