bug#45200: Memory leaks: (garbage-collect) fails to reclaim memory

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Sure, they have my report on the problem. In my text I was just trying to
> convince Stefan that this is not correct behaviour, whereas he was
> implying otherwise.

I'm not saying it's necessarily correct behavior.
What I'm saying is that the expectation that the temporary use of 200MB
should not affect the memory use later is unrealistic.

And also that if you (setq gc-cons-threshold most-positive-fixnum)
then you're simply asking for trouble unless you *really* know what
you're doing (in which case you'd understand that the above expectation
is unrealistic).

> Glibc could for example use statistics of previous allocation patterns
> to see if it's needed to release memory and how much, but this is not
> what happens. And I am not the only dissatisfied user. Ruby for
> example too¹. Also, many people experience strange memory usage grow
> with Qutebrowser that nobody knows where it's coming from; and after
> today's research I suspect Glibc is the culprit (I don't have yet
> enough evidence because my Qutebrowser instance doesn't have much
> uptime ATM, but attaching to it with gdb and calling `malloc_trim`
> inside it already freed ≈40M of memory to me today). Glib also seems
> affected².

Memory management is hard, and lots and lots of things can go wrong.
Maybe you're right and they're all due to some underlying problem
in glibc.  I suspect that instead the only thing in common is that
they're all problems with the memory management.


        Stefan