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

From: Eli Zaretskii <[email-masked]>
Date: Mon, 04 Apr 2022 15:25:07 +0300

> Feedback-ID:[email-masked]
> From: Mattias Engdegård <[email-masked]>
> Date: Mon, 4 Apr 2022 13:57:54 +0200
> Cc: [email-masked], [email-masked]
> 
> 4 apr. 2022 kl. 13.38 skrev Eli Zaretskii <[email-masked]>:
> 
> > 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).