GNU bug report logs - #54698
non-recursive GC marking [PATCH]

Previous Next

Full log

Message #26 received at 54698 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: larsi <at> gnus.org, 54698 <at> debbugs.gnu.org
Subject: Re: bug#54698: non-recursive GC marking [PATCH]
Date: Mon, 04 Apr 2022 15:25:07 +0300

> Feedback-ID:mattiase <at> acm.or
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Mon, 4 Apr 2022 13:57:54 +0200
> Cc: larsi <at> gnus.org, 54698 <at> debbugs.gnu.org
> 
> 4 apr. 2022 kl. 13.38 skrev Eli Zaretskii <eliz <at> 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).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.