GNU bug report logs - #75322
SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)

Previous Next

Package: emacs;

Reported by: Pip Cet <pipcet <at> protonmail.com>

Date: Fri, 3 Jan 2025 17:21:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: pipcet <at> protonmail.com, 75322 <at> debbugs.gnu.org
Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Date: Sun, 05 Jan 2025 19:31:06 +0200
> 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.

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




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.