bug#54532: [PATCH] sorting

[Andrew Cohen]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

[...]

    EZ> If this is just temporary, then how about disabling GC (using
    EZ> inhibit_garbage_collection) during this stage instead?  

I don't see why that wouldn't work, but I would defer to others who
understand these issues better then me.

    EZ> Do we expect to have a lot of garbage generated while this
    EZ> particular part of the code runs?  Does this code call some Lisp
    EZ> about whose consing behavior which we cannot assume anything?
    EZ> If we can be certain we won't have a lot of garbage during this
    EZ> stage, disabling GC is just TRT, IMO.

The only lisp that gets called is the predicate used in the merging
(deciding which element precedes and which follows); in principle this
predicate can be any lisp code so I don't think we can assume much about
its behavior, and while doing a lot of consing is probably rare I don't
think we can rule it out.

    EZ> In general, having marked Lisp objects should be avoided,
    EZ> because examining those objects in GDB is tricky at best, and
    EZ> because some functions/macros will hit assertions if passed such
    EZ> an object.  Two examples are ASIZE and ASET.  When inside GC,
    EZ> the use of marked objects is unavoidable, but AFAIU this patch
    EZ> also marks those Lisp objects while they are in the heap, and GC
    EZ> is not necessarily running, is that right?

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;

Best,
Andy
-- 
Andrew Cohen