bug#69706: 30.0.50; sort.c, unnecessary GC marking

[Gerd Möllmann]

Mattias Engdegård <mattias.engdegard@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
;-).