GNU bug report logs -
#75322
SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Previous Next
Full log
Message #170 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 14:21:04 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > 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.
>
> This surprises me because on the master branch SAFE_ALLOCA_LISP either
> calls alloca or xzalloc. So I don't see why SAFE_ALLOCA_LISP would be
> safer in the old GC than SAFE_NALLOCA. It's only on the igc branch
> that you made SAFE_ALLOCA_LISP make a Lisp vector.
> But this is a tangent from my POV. I would like to discuss the new
> GC, not the old one.
>
This in SAFE_ALLOCA_LISP_EXTRA
(buf) = xzalloc (alloca_nbytes); \
record_unwind_protect_array (buf, nelt); \
makes a specpdl entry, which makes mark_specpdl do this:
case SPECPDL_UNWIND_ARRAY:
mark_objects (pdl->unwind_array.array, pdl->unwind_array.nelts);
break;
>> > 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.
>
> But I presume that if we have more Lisp objects, GC will happen
> sooner, no? So increasing GC pressure is not zero-cost, because more
> frequent GC means more CPU processing that stops our application
> thread.
I don't know what exact consequences that has. MPS is at least an
incremental collector, so it's not normally the case that the GC
_starts_ at some given point.
What certainly happens is that the array is allocated from an allocation
point which has a certain amount of memory pre-allocated. And that
pre-allocated memory will run out sooner, in which case the allocation
point will acquire additional memory, which potentially requires some
amount of GC.
And so on. So it will have some effect, for sure, but I don't remember
the docs spelling out details. Maybe someone else knows.
>
>> 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.
>
> But more memory allocated via xmalloc doesn't increase the frequency
> of GC, does it?
Xmalloc no, but as I said above...
This bug report was last modified 146 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.