From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dave Abrahams Newsgroups: gmane.emacs.devel Subject: Re: Emacs bzr memory footprint Date: Thu, 13 Oct 2011 11:05:41 -0400 Message-ID: References: <83fwix2osa.fsf@gnu.org> <834nzd2eil.fsf@gnu.org> <83zkh50x0j.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1318519134 31877 80.91.229.12 (13 Oct 2011 15:18:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 13 Oct 2011 15:18:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 13 17:18:50 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1REN3Z-0005qu-Gb for ged-emacs-devel@m.gmane.org; Thu, 13 Oct 2011 17:18:50 +0200 Original-Received: from localhost ([::1]:60607 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REN3Z-0006Hc-0V for ged-emacs-devel@m.gmane.org; Thu, 13 Oct 2011 11:18:49 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REN3W-0006HK-5Z for emacs-devel@gnu.org; Thu, 13 Oct 2011 11:18:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1REN3U-0003lD-OM for emacs-devel@gnu.org; Thu, 13 Oct 2011 11:18:46 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:35952) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REN3U-0003kz-Cr for emacs-devel@gnu.org; Thu, 13 Oct 2011 11:18:44 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1REN3S-0005nk-Sm for emacs-devel@gnu.org; Thu, 13 Oct 2011 17:18:42 +0200 Original-Received: from 207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com ([207.172.223.249]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Oct 2011 17:18:42 +0200 Original-Received: from dave by 207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Oct 2011 17:18:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 38 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 207-172-223-249.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (darwin) Cancel-Lock: sha1:U7bbNi/gBPU8aDneeoT88Tqmjw0= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145135 Archived-At: on Thu Oct 13 2011, Eli Zaretskii wrote: >> From: Dave Abrahams > >> Date: Thu, 13 Oct 2011 10:10:19 -0400 >> >> >> on Thu Oct 13 2011, Eli Zaretskii wrote: >> >> >> Are there known leaks with erlang-mode or haskell-mode? >> > >> > There can be no memory leak on the Lisp side. Any leaks are always >> > bugs in Emacs, not in any Lisp code that it runs. >> >> I'm not an expert on Emacs internals, but I think that depends on >> whether they are memory leaks or "memory leaks," the latter being when >> references are held longer than necessary. Also, presumably, until >> something forces a garbage collection, even unreferenced memory may >> appear to be "in use." > > Well, that's true, but then this is not a "memory leak", it's > incorrect use of memory. > > Actually, the more I think about this, the more I wonder how would a > Lisp program "keep around" unneeded objects. Maybe if it interns many > symbols, or defines a lot of global variables. Or maybe I'm missing > something. Let's put it this way: I think a Lisp program needs to > work very hard to produce this kind of "leaks". Typical examples arise with caches of various sorts. This is a well-known phenomenon in the Java world, and there's nothing particular to lisp or Java that should make lisp any different. -- Dave Abrahams BoostPro Computing http://www.boostpro.com