[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54532: [PATCH] sorting
From: |
Eli Zaretskii |
Subject: |
bug#54532: [PATCH] sorting |
Date: |
Thu, 24 Mar 2022 08:42:39 +0200 |
> From: Mattias Engdegård <mattiase@acm.org>
> Date: Wed, 23 Mar 2022 21:24:16 +0100
> Cc: Andrew Cohen <acohen@ust.hk>, 54532@debbugs.gnu.org
>
> > Can you tell more why this was needed? Emacs has conservative stack
> > marking, so any Lisp object that is referred by some stack-based variable
> > should be protected from GC. Why isn't that enough in this case?
>
> Because Lisp values are temporarily moved out to a heap allocated buffer
> which isn't traversed by the stack scanner. `record_unwind_protect_ptr_mark`
> can be seen as a generalisation of `record_unwind_protect_ptr` (because
> that's what it is).
I understand that these objects are on the heap, but AFAIU a reference
to them is on the stack, isn't it?
> > Is this really eassume, or is eassert better here?
>
> No, eassume is appropriate here. It provides more optimisation opportunities.
> In fact, most uses of eassert are better or just as good as eassume as long
> as there are no function calls or tricky memory dereferences.
I asked about a specific instance, not in general. That instance was
at the end of the function, right before it returns, and I wonder what
kind of optimization opportunities that could present.
bug#54532: [PATCH] sorting, Lars Ingebrigtsen, 2022/03/31