bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com,  75322@debbugs.gnu.org
> Date: Sun, 05 Jan 2025 14:21:04 +0100
> 
> Eli Zaretskii <eliz@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.

> > 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.

> 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?