bug#43389: 28.0.50; Emacs memory leaks using hard disk all time

[Trevor Bentley <trevor@trevorbentley.com>]

Eli Zaretskii <eliz@gnu.org> writes:
> 
> Look at the large chunks in the tail of this.  Together, they do 
> account for ~2GB. 
> 
> Carlos, are these chunks in use (i.e. allocated and not freed), 
> or are they the free chunks that are available for allocation, 
> but not released to the OS?  If the former, then it sounds like 
> this session does have around 2GB of allocated heap data, so 
> either there's some allocated memory we don't account for, or 
> there is indeed a memory leak in Emacs.  If these are the free 
> chunks, then the way glibc manages free'd memory is indeed an 
> issue. 

I just updated the log on my website.  Same instance a day later, 
after yet another memory spike up to 4.3GB.  Concatenated to the 
end:

https://trevorbentley.com/emacs_malloc_info.log

Some interesting observations:
 - (garbage-collect) takes forever, like on the order of 5-10 
 minutes, with one CPU core pegged to 100% and emacs frozen.
 - The leaking stops for a while after (garbage-collect).  It was 
 leaking 1MB per second for this last log, and stopped growing 
 after the garbage collection.

Question 1: (garbage-collect) shows the memory usage *after* 
collecting, right?  Is there any way to get the same info without 
actually reaping dead references?  It could be that there really 
were 4.3GB of dead references.

Question 2: are the background garbage collections equivalent to 
the (garbage-collect) function?  I certainly don't notice 5-10 
minute long pauses during normal use, though "gcs-done" is 
incrementing.  Does it have a different algorithm for partial 
collection during idle, perhaps?

Question 3: I've never used the malloc_trim() function.  Could 
that be something worth experimenting with, to see if it releases 
any of the massive heap back to the OS?

-Trevor