On Sun, Jun 19, 2022, 7:05 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> > 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.
>
> Wasn't there a huge discussion about this a couple months ago and the
> conclusion was that glibc rarely releases memory back to the OS?  That's
> why we added `malloc-trim'.
>

Was there?  I see:.  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38345#71
but it's a little more than a couple of months ago.
I'm pretty curious because if I accumulate a large buffer of trace output
(running memory up to 100s of MB), killing the buffer doesn't seem to
impact gc time substantially.
I would think using mmap-based allocation would make release of memory to
the system more likely.  But mmap is only used for 64+KiB size blocks, and
the trim threshold is 128KiB blocks (shouldn't it be lower than the
allocation size?)
I'm also interested in the improvement in performance reported in that
thread from using the jemalloc implementation.  Has that been investigated
further?

Thanks,
Lynn