GNU bug report logs - #54532
Faster sorting

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattiase <at> acm.org>
To: Andrew Cohen <acohen <at> ust.hk>
Cc: 54532 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#54532: [PATCH] sorting
Date: Thu, 24 Mar 2022 10:55:03 +0100

24 mars 2022 kl. 10.17 skrev Andrew Cohen <acohen <at> ust.hk>:

> No, I think they only get marked during the marking phase of a
> GC. Mattias' implementation simply adds a callback to do the actual marking
> that is invoked in mark_specpdl:
> 
> case SPECPDL_UNWIND_PTR:
> if (pdl->unwind_ptr.mark)
>   pdl->unwind_ptr.mark (pdl->unwind_ptr.arg);
> break;

Right -- it's really just a generalisation of the existing `record_unwind_protect_ptr` and fills a gap that wasn't properly handled before. The other unwind handlers in the family already take care of marking:

record_unwind_protect:
  takes a single Lisp_Object, which is marked.
record_unwind_protect_array:
  takes a heap-allocated array of Lisp_Objects, which are all marked.
record_unwind_protect_int:
  takes an int, which does not need marking.

and so on. `record_unwind_protect_ptr` stands out because it takes a generic pointer and unwind function, but does not account for the possibility that anything referred to by that pointer may need marking. `record_unwind_protect_ptr_mark` plugs that hole in a very natural way.

I don't think we should disable the GC during sorting; the predicate function is not restricted in what it can do. It could build data structures, throw, call sort on another sequence, switch threads, and so on.

Previous Next

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