GNU bug report logs -
#75322
SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Previous Next
Full log
Message #155 received at 75322 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: pipcet <at> protonmail.com, 75322 <at> debbugs.gnu.org
>> Date: Sun, 05 Jan 2025 12:37:42 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> If you mean the two patches I sent with "these two", then no. I prefer
>> >> using SAFE_ALLOCA_LISP because that introduces an exact root.
>> >
>> > I guess I'm confused, then. The first patch replaces calls to
>> > SAFE_NALLOCA by SAFE_ALLOCA_LISP, the second patch modifies
>> > SAFE_NALLOCA to call igc_xnmalloc_ambig. That's why I thought they
>> > were alternatives.
>> >
>> > If they are not alternatives, then why did you replace SAFE_NALLOCA in
>> > the first patch?
>>
>> I checked other uses of SAFE_NALLOCA that were not yet mentioned, and
>> found another problematic case. (Something with struct itree_node *,
>> don't remember the function name, it's in some other mail). There were
>> too many grep hits for SAFE_NALLOCA for me, so I shot with a canon :-).
>
> OK.
>
> So can we talk about the relative merits and demerits of using
> SAFE_ALLOCA_LISP vs SAFE_NALLOCA?
Let me add a (0): I assume that SAFE_ALLOCA_LISP is the right thing in
the _old_ GC, because it makes sure objects referenced in the xmalloc'd
memory are marked. From my POV, it would require a very good reason to
use something else, which is nowhere mentioned. That's why I suspect
it's a left-over from times where SAFE_ALLOCA_LISP didn't exist.
(And I very much hope it's not the old pattern of "I don't need to GCPRO
this because I know this is already protected because of so-and-so",
which you might still remember from the old times. In which cases I
would've liked to hit people with a GCPRO on their head when I had to
debug that and so-on-so was no longer true :-).)
> First, why is it better to have an exact root than an ambiguous root?
In the most general case, where an ambiguous root can contain random bit
patterns, say the C stack, I'd say the greatest advantage of exact roots
is avoiding false positives that keep objects alive, or prevent copying
them.
In the specific here case, where a root actually contains only
Lisp_Objects, and not random patterns, I'd say the advantage of exact
roots is that they don't prevent copying.
The "prevent copying" disadvantage is a bit hand-wavy, and depends a lot
on the GC implementation. Maybe a good picture of it that one would like
to have a fully copying collector, with its advantage of reducing
fragmentation, for example, but one can only have a mostly-copying
collector, because of ambiguous references. The more the "mostly" is
true the better for the copying/fragmentation. Does that make sense?
> And second, SAFE_ALLOCA_LISP conses a Lisp vector, which will increase
> GC pressure, so isn't SAFE_NALLOCA preferable at least in some cases?
SAFE_ALLOCA_LISP allocates a Lisp vector, that's true. I think one can
say that allocation is cheap on average. The overhead of freeing it is
not copying it, which is basically zero.
SAFE_NALLOCA, with my patch, requires a xmalloc, creation of a MPS root
object, deletion of that, and xfree.
Let's assume scanning costs are more or less the same because the
number of references is the same in both cases.
I think SAFE_NALLOCA is more expensive,
This bug report was last modified 147 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.