Re: (heap 1024 82721 1933216)

[Daniel Colascione <dancol@dancol.org>]

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.