GNU bug report logs - #69706
30.0.50; sort.c, unnecessary GC marking

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 69706 <at> debbugs.gnu.org
Subject: Re: bug#69706: 30.0.50; sort.c, unnecessary GC marking
Date: Sun, 10 Mar 2024 12:29:11 +0100

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

>>> sort.c uses record_unwind_protect_mark to let GC mark some objects in
>>> its merge_state structure, while GC marks the specpdl stack.
>>> 
>>> This is
>>> 
>>> - unnecessary because all the objects that are currrently extra
>>>  protected by merge_markmem, are already seen by the GC, because these
>>>  are the objects being sorted, which are protected in the usual way
>>>  (marking the control stack, ...)
>
> Thank you Gerd, but I don't think we can guarantee that those objects
> are present anywhere else -- the original vector is being mutated by
> the algorithm, after all.

You nean sort.c is removing objects temporarily from the vector, so that
they are not reachable from any other root, especially from the control
stack? Could be, the code is a bit hard to follow.

OTOH, I think it would not be too hard to make such objects reachanble
from control stack...

> In addition, I have Grand Plans (well, some kind of plans) for an
> improvement to the sorting code that will likely require
> record_unwind_protect_mark or an equivalent facility. A new bug will
> be opened about that.

Please make it easy for a concurrent, mostly-copying GC, use the stack
;-).

Previous Next

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