Re: MPS GC and its implications

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 01 May 2024 19:17:01 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How do you see that it's a static array of structs?
> 
> a326d6aed816c19f66729a7ff77d90ef6bcec07c
> Author:     Helmut Eller <eller.helmut@gmail.com>
> AuthorDate: Tue Apr 30 11:04:54 2024 +0200
> Commit:     Gerd Möllmann <gerd@gnu.org>
> CommitDate: Tue Apr 30 20:59:38 2024 +0200
> 
> Parent:     44100e5b081 Add missing #ifdef HAVE_MPS
> Merged:     emacs-29
> Contained:  scratch/igc
> Follows:    igc-first-commit (76)
> 
> Staticpro coding_categories
> 
> * src/coding.c (syms_of_coding):
> 
> 1 file changed, 10 insertions(+)
> src/coding.c | 10 ++++++++++
> 
> modified   src/coding.c
> @@ -11848,6 +11848,16 @@ syms_of_coding (void)
>  
>    Vcoding_category_table = make_nil_vector (coding_category_max);
>    staticpro (&Vcoding_category_table);
> +  for (size_t i; i < ARRAYELTS (coding_categories); i++)
> +    {
> +      struct coding_system* cs = &coding_categories[i];
> +      Lisp_Object *src = &cs->src_object;
> +      *src = Qnil;
> +      staticpro (src);
> +      Lisp_Object *dst = &cs->dst_object;
> +      *dst = Qnil;
> +      staticpro (dst);
> +    }
>    /* Followings are target of code detection.  */
>    ASET (Vcoding_category_table, coding_category_iso_7,
>  	intern_c_string ("coding-category-iso-7"));

I'm not sure I get your point.  The contents of coding_categories[] is
AFAIK never used to actually encode or decode something.  It is just a
handy db of known coding categories for using in all kinds of APIs
that need to examine the known categories for some reason or other.

> > I thought we agreed that all the global variables with Lisp objects
> > need to be staticpro'd, didn't we?  If we do that, we are covered for
> > anything that comes from there, no?
> 
> See the commit at the start. It seems coding_categories isn't
> Lisp_Objecut and thus cannot be staticpro'd.

I'm not sure I understand why we need that loop.  The src_object and
dst_object members of coding_categories[] is AFAICT never used
anywhere.  The values of src_object and dst_object were AFAICT never
set in the elements of coding_categories[], they are only set now by
that loop, and for what purpose? just so we could staticpro them?

In general, these are coding categories, not coding systems, AFAIK
they are just stored as coding-systems because that's convenient.

> >> It's basically like with the old GC. Nothing makes sure that the window
> >> has survived when bar is called, withput staticpro. The difference to
> >> the MPS GC is that my_special_window might have survived in the old GC
> >> because something else keeps it alive and that is all we need (fond
> >> memories of GCPRO, booooh ;-)).
> >
> > The old GC didn't move objects.  So the window could have been deleted
> > meanwhile, but its 'struct window' couldn't have moved to a different
> > address in memory.
> 
> Hm, I don't understand where you are aiming. I find the code is
> incorrect because nothing really guarantees, in code, that
> my_special_window is live when bar is called. Unless we staticpro.

staticpro doesn't guarantee that the window is live, either.  Unless
we are talking about two different meanings of "live".  What I meant
by "live" is a window that was not deleted meanwhile; that can be
tested with WINDOW_LIVE_P.

The old GC didn't delete windows; if a window was live before GC, it
would still be live after GC, and its 'struct window' will be at the
same address.  By contrast, with MPS a live window could move to a
different address, so my pointer will no longer point to it after GC.