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

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-12-10 22:21]:
> > 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.
> 
> Indeed, that makes no sense.  The only thing that comes to mind is that
> when they do `M-x garbage-collect` the 15 minutes aren't actually spent
> in the GC but in some pre/post command hook or something like that
> (e.g. in `execute-extended-command--shorter`)?
> 
> Do we have a `profiler-report` available for those 15 minutes?
> I've taken a quick look at the massive threads in that bug report,
> but haven't had the time to read in detail.  AFAICT we don't have a
> profiler output for those 15minutes, so it would be good to try:
> 
>     M-x profiler-start RET RET
>     M-x garbage-collect RET     ;; This should presumably take several minutes
>     M-x profiler-report RET

Another issue is that since I use LD_PRELOAD with gmalloc trace is
that I have not encountered high swapping and Emacs being totally
unusable. And I have not upgraded Emacs. Changed basically nothing but
using the mtrace.

What I can still observe is that vsize grows high as usual. But I have
not observed swap growing high or that hard disk starts working to
find some swap memory for 40 minutes or longer indefinitely maybe.