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

[Eli Zaretskii <eliz@gnu.org>]

Stefan, please help with this complex issue (or maybe several
issues).  We have collected some evidence in this bug report, but I
don't yet see where is this going, or how to make any real progress
here.

One thing that I cannot explain is this:

> From: Trevor Bentley <trevor@trevorbentley.com>
> Cc: fweimer@redhat.com, 43389@debbugs.gnu.org, bugs@gnu.support,
>  dj@redhat.com, michael_heerdegen@web.de
> Cc: 
> Date: Tue, 08 Dec 2020 22:50:37 +0100
> 
> I've been too busy to modify emacs to print garbage collects, but 
> these still show really long (garbage-collect) calls, often 
> exceeding 15 minutes.

Trevor reported several times that automatic GC is fast as usual, but
manual invocations of "M-x garbage-collect" take much longer, many
minutes.  I don't understand how this could happen, because both
methods of invoking GC do exactly the same job.

I thought about possible ways of explaining the stark differences in
the time it takes to GC, and came up with these:

 . The depth of the run-time (C-level) stack.  If this is much deeper
   in one of the cases, it could explain the longer time.  But in that
   case, I'd expect the automatic GC to take longer, because typically
   the C stack is relatively shallow when Emacs is idle than when it
   runs some Lisp.  This contradicts Trevor's observations.

 . Some difference in buffers and strings, which causes the manual GC
   to relocate and compact a lot of them.  But again: (a) why the
   automatic GC never hits the same condition, and (b) I can explain
   the reverse easier, i.e. that lots of temporary strings and buffers
   exist while Lisp runs, but not when Emacs is idle.

Any other ideas?  Any data Trevor could provide, e.g. by attaching a
debugger during these prolonged GC, and telling us something
interesting?

TIA