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 17:51:47 +0200
> 
> > First, I don't understand why the above mechanism doesn't work.  What
> > exactly are the conditions which ensure that "ambig scanning of
> > registers and the C stack" will work?
> 
> The condition is: Some automatic C variable in the stack frames makes it
> so that either the stack itself or a register contains the reference, in
> this case a pointer to the string data (maybe interior pointer).
> 
> That's not the case, or not guaranteed, for example, if we store the
> string pointer in some global variable, in our case in a struct member
> of a static array of structs.

How do you see that it's a static array of structs?

The way a coding_system is usually set when starting an
encoding/decoding operation is like this:

  Lisp_Object
  code_convert_string (Lisp_Object string, Lisp_Object coding_system,
		       Lisp_Object dst_object, bool encodep, bool nocopy,
		       bool norecord)
  {
    struct coding_system coding;
    [...]
    setup_coding_system (coding_system, &coding);
    [...]
    if (encodep)
      encode_coding_object (&coding, string, 0, 0, chars, bytes, dst_object);
    else
      decode_coding_object (&coding, string, 0, 0, chars, bytes, dst_object);

So the pointer to a 'struct coding_system' that is thereafter passed
from encode_coding_object/decode_coding_object downwards (and
eventually ends up in coding_set_source etc.), starts as a stack-based
automatic variable at the top-level caller.  Isn't that what we need
for MPS to DTRT with any pointers to Lisp objects in 'struct
coding_system'?

> > Anyway: 'struct coding_system' is passed as argument to the functions
> > involved in the en/decoding, and so is on the stack or in a register.
> 
> If it's passed by value, we are fine. If its passed as a pointer we're
> not because the char * in question is not an the stack.

See above: it _is_ on the stack, right?

> If it passed by value but was originally copied from a static
> counterpart, we are probably not good, because that would copy the char
> * from something we haven't traced.

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?

> > Similarly for buffer text: the buffer object is a member of 'struct
> > coding_system', which is on the stack, and the 'char *' points to the
> > text of that buffer.
> 
> Same as above for strings: if we're passing the struct around by value
> etc.

Is MPS tracing buffer text?  I'm looking at fix_buffer, and I don't
see where we do something with the own_text->beg there.  Is that
because the text is allocated not by MPS, and therefore isn't moved by
GC?

> > What if I do something like this:
> >
> >  static struct window *my_special_window = NULL;
> >  void foo (Lisp_Object window)
> >  {
> >    my_special_window = XWINDOW (window);
> >    ...
> >  }
> >  void bar (void)
> >  {
> >    if (my_special_window != NULL)
> >      /* do something with my_special_window */
> >  }
> >
> > IOW, is storing a pointer like above in a temporary global variable
> > safe?
> 
> You need to staticpro.
> 
> 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.

> >> I think the only thing you missed is why the automatic ambig scanning of
> >> registers and control stack is not sufficient in Helmut's case (the
> >> struct containing the char * etc.).
> >
> > Why is it not safe?  I still don't think I understand that.
> 
> It is the missing reference from the stack. DOes the above help somewhat?

Depends on how you answer my questions and observations above.