From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Tue, 06 Dec 2011 14:53:46 -0500 Message-ID: References: <4ED0F945.5090805@yandex.ru> <83pqge7syw.fsf@gnu.org> <87mxb6tkji.fsf@wanadoo.es> <87borlu0kc.fsf@wanadoo.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1323201239 26899 80.91.229.12 (6 Dec 2011 19:53:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Dec 2011 19:53:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 06 20:53:54 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 1RY15O-0001oV-0H for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 20:53:54 +0100 Original-Received: from localhost ([::1]:36202 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY15N-0006hh-K5 for ged-emacs-devel@m.gmane.org; Tue, 06 Dec 2011 14:53:53 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:33175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY15K-0006Pz-Hu for emacs-devel@gnu.org; Tue, 06 Dec 2011 14:53:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RY15J-0006X6-9r for emacs-devel@gnu.org; Tue, 06 Dec 2011 14:53:50 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:39807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY15J-0006X0-1n for emacs-devel@gnu.org; Tue, 06 Dec 2011 14:53:49 -0500 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id pB6JrlWJ027753; Tue, 6 Dec 2011 14:53:47 -0500 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 3ED44B42C1; Tue, 6 Dec 2011 14:53:47 -0500 (EST) In-Reply-To: <87borlu0kc.fsf@wanadoo.es> (=?iso-8859-1?Q?=22=D3scar?= Fuentes"'s message of "Tue, 06 Dec 2011 17:28:19 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4063=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4063> : streams <708372> : uri <1022936> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:146513 Archived-At: > I'm writing this message on that very same emacs process. Right now it > has 60 buffers, all of them with a size below 50KB and most below > 10KB. As reported by `htop', the process is using 533MB of RES memory > and 630MB of VIRT memory. Nothing of what you say sounds worrisome: apparently you now have around half a GB of memory allocated for use by Lisp data. Most likely the majority of it is considered by Emacs as "free for reuse", but it's not returned to the OS because that is only done in "big chunks" (typically 10KB or so) and none of the big chunks are 100% free (they all contain at least one non-free object). Some of that memory may also belong to malloc rather than to Emacs: Emacs did pass it to `free', but the malloc library decided that it's not worth returning those elements to the OS. Of course, it may also be that we have an actual leak (i.e. some of that memory was neither returned to malloc, nor is it still managed by Emacs). But as long as you don't have evidence of a leak, I'd suggest you move on, because there's really not much we can do about the above problem (short of rewriting the whole memory management to make it compacting). Stefan