bug#54698: non-recursive GC marking [PATCH]

[Eli Zaretskii]

> Feedback-ID:mattiase@acm.or
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Mon, 4 Apr 2022 13:57:54 +0200
> Cc: larsi@gnus.org, 54698@debbugs.gnu.org
> 
> 4 apr. 2022 kl. 13.38 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > What happens with data that GC relocates, like when it relocates and
> > compacts string data?  If the relocated data is allocated on the heap
> > after the simulated stack, the original string data, which is now free
> > memory, will be "trapped" behind the simulated stack, and 'free' will
> > be unable to return it to the OS.  This could make the memory
> > footprint of Emacs larger than it could be.
> 
> That effect is unlikely to be visible. I don't think a single (and not very 
> big) allocation would contribute materially to heap fragmentation, given the 
> amount of allocation being made all the time. (But prove me wrong!)

I don't need to prove you wrong: if the problem is real, we will hear
about that soon enough.

In principle, even a small allocation can prevent a large free portion
of the arena from being returned to the OS.  And Lisp strings nowadays
tend to be a legion and some quite large in some applications, because
many packages abuse them (instead of using temporary buffers).