Re: How to debug memory leaks

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

No, no, I don't mean that some modes don't need undo. I mean, if I am
working in a buffer, say some C file, and I think Emacs get sluggish, I
could do some M-x clean-buffer and have it setq bunch of variables to
nil, amongst them undo so GC can collect them. It is just that these
variables might be different depending of type of buffer, active modes
etc. I can of course do my own interactive command. But it is maybe
better if there was a "standard" hook which mode writers can use, and
standard command, so users like me don't need to write their own.

>> >> 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.

Ok, I didn't know I can use post-command-hook for that. I'll try and
play with it. Thanks.

> 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.

To be honest, I don't really think it is very much needed, more of a "in
case of" thing. Lately I haven't experienced any memory problems with
Emacs, and it feels fast and responsive as ever before. So well done job
there.

>> 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.

Ok, seems like it works well now.