Re: Larger GC thresholds for non-interactive Emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Ihor Radchenko <yantar92@gmail.com>,  Mattias Engdegård
>  <mattiase@acm.org>,  Eli Zaretskii <eliz@gnu.org>,  Tim Cross
>  <theophilusx@gmail.com>,  rms@gnu.org,  Alan Mackenzie <acm@muc.de>,
>   emacs-devel <emacs-devel@gnu.org>
> Date: Sat, 18 Jun 2022 14:49:49 +0200
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Obviously this process ends up with a very large one-step allocation
> > which is arguably interesting in itself (I suspect there's some
> > GC-inhibition going on there), but the more interesting point
> > is that with p=0.1 we get an amount of free space after GC
> > (i.e. blocks we can't release, because of fragmentation) that's about as
> > large as the next threshold, i.e. about 10%, whereas with p=1.0 this
> > amount of unreleasable free space is significantly higher.
> 
> As far as I know, we never actually release back cons space to the OS
> anyway -- even if we could.  (Because glibc's malloc implementation
> doesn't do that unless we call that trim function, which we don't.)

AFAIK, that's not really true.  We call 'free' and glibc does release
to the OS when it can.  And don't forget that Emacs calls 'malloc' a
lot not just for conses and other Lisp data.