Re: Not protecting Lisp objects from GC

[Stefan Kangas]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

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

As I said in Bug#75521, I'll reiterate here for the record: I believe we
should remove DEFVAR_LISP_NOPRO and avoid pursuing these kinds of
optimizations.

Additionally, the comment in font.c about "wasting slots" in staticvec
seems misleading.  There's plenty of free space in staticvec, and adding
three more elements is quite unlikely to have any significant impact on
paging behavior.