From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: emacs user Newsgroups: gmane.emacs.devel Subject: Re: Memory again Date: Mon, 19 Dec 2011 21:51:06 +0200 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: dough.gmane.org 1324324279 1366 80.91.229.12 (19 Dec 2011 19:51:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 19 Dec 2011 19:51:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 19 20:51:15 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 1RcjEw-0006us-1o for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2011 20:51:15 +0100 Original-Received: from localhost ([::1]:39946 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcjEv-0008IK-Dc for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2011 14:51:13 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:44848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcjEs-0008Gb-OA for emacs-devel@gnu.org; Mon, 19 Dec 2011 14:51:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RcjEr-0003T3-Cv for emacs-devel@gnu.org; Mon, 19 Dec 2011 14:51:10 -0500 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:65288) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RcjEr-0003Sy-79 for emacs-devel@gnu.org; Mon, 19 Dec 2011 14:51:09 -0500 Original-Received: by wgbdt11 with SMTP id dt11so9137476wgb.30 for ; Mon, 19 Dec 2011 11:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=QIrRGCqrQ2YVMsG1PugiHBq6yLY1yT3s6/NVl2FBNrk=; b=n+rDuHVwSt8VzTBkDWzSShTPNNCOnEGk3bywbVezrZZkD5765MiuAeW7BsLiNQk4Eg QmyZlONSmsUqL98YIMajlbEuql6g2/3FAT26IelOZEDkvGXt9RJWscZdkGGvI0At86TD g0/3WRItfFuOh5UelkhpGINELPS6+bz+AG3bA= Original-Received: by 10.216.143.206 with SMTP id l56mr5191892wej.46.1324324266422; Mon, 19 Dec 2011 11:51:06 -0800 (PST) Original-Received: by 10.216.170.138 with HTTP; Mon, 19 Dec 2011 11:51:06 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.82.49 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:146843 Archived-At: For whatever it's worth, I need to kill my emacs (GNU Emacs 24.0.92.1 x86_64-apple-darwin11.2.0, NS apple-appkit-1138.23) several times a day when it reached over 300mb or it will crash. This memory usage is *after* I kill all buffers and do M-x garbage collect. I submitted a couple of bug reports, please see http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-12/msg00404.html am happy to do additional tests if anyone could guide me. -------------------------------------------- From: Stefan Monnier Subject: Re: Memory again Date: Mon, 19 Dec 2011 06:26:26 -0500 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) >> `garbage-collect' is supposed to give that info. At least it does give >> info about the data that's kept under alloc.c's control because >> of fragmentation (these are counted as "free cells"). > I would like to propose a function which explicitly says how much free memory > the Emacs process holds. For the part that alloc.c holds, the "memory-usage" package in ELPA should do the trick (or can be improved to do it). > It's especially useful when there is a way to ask system malloc about > how much free memory is in the heap. It'd be great to add this data when available, indeed. Patch welcome. > This may be helpful to distinguish real heap fragmentation from memory > leaks and other misuses - if the sum of values returned by > 'memory-free' is, say, 10% of heap size, then the real fragmentation > enters into the game. It may also be important to try and keep track of other allocations, which are not under alloc.c's control (e.g. allocations performed by GUI libraries). >> I agree that we're probably going to see better overall results by >> improving general memory use than by trying to attack >> fragmentation problems. > Among this list's subscribers, Nix is constantly > reporting an enormous memory usage caused by Gnus. I think we still have a leak there somewhere. Stefan