[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69706: 30.0.50; sort.c, unnecessary GC marking
From: |
Mattias Engdegård |
Subject: |
bug#69706: 30.0.50; sort.c, unnecessary GC marking |
Date: |
Sun, 10 Mar 2024 14:38:38 +0100 |
10 mars 2024 kl. 12.29 skrev Gerd Möllmann <gerd.moellmann@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:
> /* 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.
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.