[Top][All Lists]

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

Re: (heap 1024 82721 1933216)

From: Daniel Colascione
Subject: Re: (heap 1024 82721 1933216)
Date: Sat, 18 Jan 2014 20:24:21 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 01/18/2014 08:19 PM, Stefan Monnier wrote:
Could be.  For an Emacs that grew to 6GB, I don't find it worrisome
if it doesn't shrink back below 2GB.
Longer-term, it would be nice to be able to compact objects. We could move
objects during the unmark phase of GC by looking for forwarding pointers to
new object locations. (Of course, objects found through conservative
scanning would have to be considered pinned.)

Lots of work for *very* little benefit.  I've pretty much never seen
a case where a user is really annoyed just by Emacs's size "after
freeing everything".  In pretty much all cases, the user was already
annoyed at Emacs's size *before* freeing everything, so that's the
problem to solve.  Once this problem is solved, the fact that the memory
is not very much returned to the OS is usually not a problem any more.

At the very least, we can add internal fragmentation statistics to the return value of Fgarbage_collect.

And FWIW, I've heard complaints about Emacs using too much memory and never returning it to the system.

I'm much more worried about: how on earth did it grow to 6GB?
I have no idea --- I was just doing normal editing over a few dozen files.

Yet, *that* is the problem.  The fact that freeing everything didn't let
you work around this problem is of very little concern.

So if you ever bump into such a situation, don't bother trying to free
stuff, and instead try and figure out what is eating all that memory.

That's a separate issue. Regardless of other concerns, the malloc heap should never get this fragmented.

reply via email to

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