Re: Not protecting Lisp objects from GC

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Mon, 27 Jan 2025 10:08:17 +0100
> 
> I've just noticed the latest commit in the igc branch, which adds to the
> comment of DEFVAR_LISP_NOPRO, and together with what I've seen in other
> discussions, I feel I have to say something.
> 
> I'm talking about the old GC, and it is _bad_ to not protect GC'able
> objects because
> 
> - they are protected from GC by being referenced from other objects that
>   we '"know" are protected from GC
> 
> - because a GC "cannot happen"
> 
> And there are _no_ exceptions.
> 
> I'm speaking as a software engineer with decades of experience in
> commercial software projects, and also from my experience as Emacs'
> maintainer. Back then, even local variables had to be protected from GC
> with a macro named GCPRO. And that was used in many places making
> exactly the above assumptions.
> 
> I called that "aggressive use of GCPRO".
> 
> Aggressive because it's unmaintainable. I cannot possibly describe what
> a debugging nightmare it was when the assumptions were no longer true
> and some GCPRO was now missing because of innocent changes kilometers
> away in a call tree.
> 
> And now I see the same assumptions being made in other circumstances,
> and it seems nothing has ever been learned.
> 
> Anyone, please stop doing this. It's *BAD*.

Gerd,

No one is disagreeing with you, at least not IMO.  I'm not aware of
any code we added lately that consciously avoids GC-protecting data
which should be protected.  We may have existing code which does that,
yes, and when we find it, we generally try to plug those holes,
especially on the igc branch, where we sometimes find that what didn't
have to be protected before must be protected now.  But we don't add
any new code under such incorrect assumptions.

As for the offending commit, it just added a description of the
purpose of DEFVAR_LISP_NOPRO and how it is currently used, that's all.
It didn't suggest to use it more or anything like that.