Re: How to debug memory leaks

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Fri, 26 Mar 2021 16:53:58 +0100
> 
> >> Yes, but GC can't know if I don't need undo history, right
> >
> > And neither do you.  GC compacts the undo history, though, and frees
> > the slack.
> 
> Ok, good if GC compacts the undo, but I could explicitly wish/know
> sometimes that I could "freeze" the undo. I could just put on my own
> interactive command that does this instead of using
> M-: (setq buffer-undo-list nil), but there could be some other stuff
> based on mode, like eshell or term or I don't know what. That could help
> GC.

You will have to come up with more specific ideas, the above is too
general to be useful.  If you suggest that some modes don't need undo,
then I don't think I agree.

> >> or old text in eshell buffer?
> >
> > Delete it, and it will be free'd.
> 
> Yes, so that is what I am saying; a hook to put all kind of various
> "delete" stuff for various modes so we can run interactive command, say
> "clean-buffer" or whatever, and it will run the apropriate "deletes" and
> maybe other stuff based on mode.

You have post-command-hook already; if you want to keep only a small
part of a shell buffer, you can use that hook to delete the old
stuff.  This is clearly specific to your use patterns, though.

And after all that, please keep in mind that in all the reports about
multi-GB memory footprints that people complained about, the actual
memory used by Lisp objects (what GC can free) was quite small, almost
negligible.  The real problem, whatever it was, wasn't with GC not
freeing enough.

> Just as a note: no idea if you have found the memory leak or not, the
> big one that everyone was repporting few weeks ago, but I haven't
> experienced any leaks or slugishness with lately builds. I guess you
> found it? :).

Not really.  We fixed a problem where fiddling with some GC-related
options could cause Emacs stop calling GC, but that's all.