bug#45200: [PATCH] Force Glibc to free the memory freed

[Stefan Monnier]

> Upside indeed is the memory reduction.

I expect so, but the measurement is the thing we need here.
How much is the memory reduced (in the case where the GC vars are left
to their default value)?

> Well, I didn't send the patches for my only benefit, but for benefit of
> others people.  The new ELisp function is something that not too many people
> would benefit from, and I mean, including those who disable GC.  That is
> because it would be an opt-in feature, which you need to know about to
> enable it, and not many will ever find out about it.

If it's very useful even with the default GC settings, then there's
a good reason to say it should be enabled by default, but if not then
I'd expect that those people who set their GC vars manually will learn
to complete their GC settings by adding that function to their
`post-gc-hook`.

> For my-only benefit I could just continue building Emacs with my patch
> applied locally, as I do now.

Yes, I have my share of local patches as well ;-)
But I think there's a good case to be made that it can benefit others,


        Stefan


PS: BTW, we can arbitrarily reduce the percentage of CPU time spent in
malloc_trim by only calling it every N times rather than after every GC.