[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (heap 1024 82721 1933216)
From: |
Stefan Monnier |
Subject: |
Re: (heap 1024 82721 1933216) |
Date: |
Sat, 18 Jan 2014 23:19:02 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
>> 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.
>> 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.
Stefan
Re: (heap 1024 82721 1933216), Stefan Monnier, 2014/01/18
Re: (heap 1024 82721 1933216), Eli Zaretskii, 2014/01/19