From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: How to debug memory leaks Date: Fri, 26 Mar 2021 19:03:00 +0300 Message-ID: <83ft0hq4wb.fsf@gnu.org> References: <87pmzmihyj.fsf@robertthorpeconsulting.com> <83lfaaot5h.fsf@gnu.org> <83k0puorpb.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18044"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 26 17:03:44 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lPow4-0004aK-7s for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 26 Mar 2021 17:03:44 +0100 Original-Received: from localhost ([::1]:33018 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPow3-0001jo-94 for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 26 Mar 2021 12:03:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52622) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPovM-0001iD-Cg for help-gnu-emacs@gnu.org; Fri, 26 Mar 2021 12:03:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37331) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPovM-0001Vb-6k for help-gnu-emacs@gnu.org; Fri, 26 Mar 2021 12:03:00 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3239 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lPovL-0003Lq-GQ for help-gnu-emacs@gnu.org; Fri, 26 Mar 2021 12:02:59 -0400 In-Reply-To: (message from Arthur Miller on Fri, 26 Mar 2021 16:53:58 +0100) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:128648 Archived-At: > From: Arthur Miller > 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.