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

Previous Next

Package: emacs;

Reported by: Mattias Engdegård <mattiase <at> acm.org>

Date: Sun, 3 Apr 2022 18:42:02 UTC

Severity: normal

Tags: patch

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log


Message #20 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 14:38:44 +0300
> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Mon, 4 Apr 2022 13:16:26 +0200
> Cc: 54698 <at> debbugs.gnu.org
> 
> > Is there a max stack size?
> 
> No, the mark stack grows as needed. I see no reason to limit the size since it's going to be much smaller than the size of the heap being traced in any case.

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.

Was this aspect considered and audited/tested?




This bug report was last modified 2 years and 332 days ago.

Previous Next


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