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

Previous Next

Full log

View this message in rfc822 format

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: bug#69706: 30.0.50; sort.c, unnecessary GC marking
Date: Sun, 10 Mar 2024 15:01:59 +0100

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

> 10 mars 2024 kl. 12.29 skrev Gerd Möllmann <gerd.moellmann <at> gmail.com>:
>
>> 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.
>
> The comment in cleanup_mem is explicit about this:

Ok, too bad :-(

>
>>   /* If we have an exception while merging, some of the list elements
>>      might only live in temp storage; we copy everything remaining in
>>      the temp storage back into the original list.  This ensures that
>>      the original list has all of the original elements, although
>>      their order is unpredictable.  */
>
>
>> Please make it easy for a concurrent, mostly-copying GC, use the stack
>
> We can't use the C stack for allocations of arbitrary size,
> unfortunately.

That goes without saying. I was more thinking about having a Lisp_Vector
on the stack, maybe in the state, which is already on the stack.

> Furthermore, we currently make the (correct) assumption that explicit
> xmalloc/xfree for temporary storage is faster than allocating a Lisp
> vector in most places. If a new GC shrinks the performance gap
> sufficiently, then we could reconsider that.
>
> See bug#69709 for the new `sort` plan.

Thanks, if I find the time, I'll take a look.

So, I guess I should close this.

Previous Next

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