emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory again


From: emacs user
Subject: Re: Memory again
Date: Mon, 19 Dec 2011 21:51:06 +0200

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 <address@hidden> is constantly
> reporting an enormous memory usage caused by Gnus.

I think we still have a leak there somewhere.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]