Subject: bug#75672: 31.0.50; scratch/igc memory usage/collection issues

From: Eli Zaretskii <[email-masked]>
Date: Thu, 23 Jan 2025 09:26:23 +0200

> Date: Thu, 23 Jan 2025 01:46:51 +0000
> From: Alexis Purslane <[email-masked]>
> Cc: [email-masked]
> 
> An Emacs session got up to 1GB again (even after an M-x malloc-trim,
> which shaved like 100MB off!) so I set about trying to figure out how to
> get a GDB attached to it to dump its stderr so I could get the output of
> M-x malloc-info, but like ten minutes into that (GDB was missing some
> plugin so I couldn't run the code inside it necessary to open the file
> and redirect the output)

To avoid the need to use such complicated tricks, you could start
Emacs with stderr redirected to a file to begin with.

> suddenly it just.. freed all that memory and went down to 140MB of
> resident memory.

That's typical of glibc, and also for situations where some relatively
small chunk of used memory prevents releasing a large chunk of free
memory.  So I still don't see any signs of significant leaks here,
maybe just something related to how the MPS-managed memory is laid out
in the address space (do we even have any ways of controlling or
changing that?).

> But it /was/ resident memory, not virtual memory, that it was using,
> since it's still using 2GB of virtual memory.

You mean, Emacs now reserves 2GB, but has only 140MB committed?