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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: Eli Zaretskii <eliz@gnu.org>, fweimer@redhat.com, 43389@debbugs.gnu.org,
>  dj@redhat.com, michael_heerdegen@web.de
> From: Carlos O'Donell <carlos@redhat.com>
> Date: Wed, 25 Nov 2020 15:51:16 -0500
> 
> >  The raw massif output:
> >  http://trevorbentley.com/massif.out.3364630
> >  The *full* tree output:
> >  http://trevorbentley.com/ms_print.3364630.txt
> >  The tree output showing only entries above 10% usage:
> >  http://trevorbentley.com/ms_print.thresh10.3364630.txt
> 
> This data is pretty clear:
> 
>  1.40GiB - lisp_align_malloc (alloc.c:1195)
>  1.40GiB - lmalloc (alloc.c:1359)
>  0.65GiB - lrealloc (alloc.c:1374)
>  0.24GiB - AcquireAlignedMemory (/usr/lib/libMagickCore-7.Q16HDRI.so.7.0.0)
> --------
>  3.60Gib - In use as of the snapshot.
> 
> That's a fairly high fraction of the ~4.2GiB that is eventually in use.
> 
> With lisp_align_malloc, lmalloc, and lrealloc shooting up exponentially at the end of the run look like they are making lists and processing numbers and other objects.
> 
> This is a direct expression of something increasing demand for memory.

So, at least in Trevor's case, it sounds like we sometimes request a
lot of memory during short periods of time.  But what kind of memory
is that?

lmalloc is called by xmalloc, xrealloc, xzalloc, and xpalloc --
functions Emacs calls to get memory unrelated to Lisp data.  But it is
also called by lisp_malloc, which is used to allocate memory for some
Lisp objects.  lisp_align_malloc, OTOH, is used exclusively for
allocating Lisp data (conses, strings, etc.).

It is somewhat strange that lisp_align_malloc and lmalloc were called
to allocate similar amounts of memory: these two functions are
orthogonal, AFAICS, used for disparate groups of Lisp object types,
and it sounds strange that we somehow allocate very similar amounts of
memory for those data types.

Another observation is that since GC succeeds to release a large
portion of this memory, it would probably mean some significant
proportion of the calls are for Lisp data, maybe strings (because GC
compacts strings, which can allow Emacs to release more memory to
glibc's heap allocation machinery).

Apart of that, I think we really need to see the most significant
customers of these functions when the memory footprint starts growing
fast.