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.