Re: MPS GC and its implications (was: staticpro everything)

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 01 May 2024 08:05:27 +0200
> 
>   coding_set_source (struct coding_system *coding)
>   {
>     if (BUFFERP (coding->src_object))
>       {
>         struct buffer *buf = XBUFFER (coding->src_object);
> 
>         if (coding->src_pos < 0)
>           coding->source = BUF_GAP_END_ADDR (buf) + coding->src_pos_byte;
>         else
>           coding->source = BUF_BYTE_ADDRESS (buf, coding->src_pos_byte);
>       }
>     else if (STRINGP (coding->src_object))
>       {
>         coding->source = SDATA (coding->src_object) + coding->src_pos_byte;
> 
> I'm not sure what is with the buffer case, but the string case means
> that source can point to string data, which is in our MPS leaf_pool. I
> think we cvould use an exact scan function for that purpose, analogous
> to scan_specpdl. WSYT?

If this is indeed needed, we are in trouble.  When we take a C pointer
to buffer or string text and use it in the following code, it's
because there's a hidden assumption that GC cannot happen during the
time the C pointer is being used.  If this assumption is not true with
MPS, nothing in Emacs will work reliably.

Is this indeed a problem?  Didn't Gerd just explain to Andrea that
every object referenced from the stack or even from a register will be
automatically "fixed" if GC happens and decides to move the objects?
If so, why doesn't that solve the problem here?

More generally, what happens with text of Emacs buffers and strings
when GC runs?  I know what the old GC did, but what does the new GC
do?

A related question, no less important, is: when can MPS GC happen, and
whether there's any reasonable way of being sure that it cannot
possibly happen while certain code fragments run?  For example, the
old GC could only be triggered by a call to funcall or eval (and a
small number of similar APIs); as long as the C code didn't cause any
of these calls, we could assume GC will not happen, and so any C
pointers to Lisp objects were safe to use.  What is the equivalent of
that with MPS?  Since MPS is a moving GC, this becomes much more
important; with old GC we only had 2 object types that could move
during GC: string data and buffer text.  Now every Lisp object is in
danger of being moved by GC, AFAIU.

Am I missing something?

I think we need to have a clear picture just what are the issues with
this, because it could indeed mean a show-stopper for Emacs.  So I
suggest that we stop for a moment and discuss these aspects of MPS.

(And please don't say "read the docs": I find the documentation of MPS
on these issues rather impenetrable; it looks like it was meant for
people who already know a lot about GC strategies and techniques.
E.g., they have 2 chapters on design: "Old Design" which is said to be
outdated at places (but no indications of where those outdated places
are), and "Design" which is described as "intended for developers of
the MPS".  IOW, there's no design description that can be relied
upon.)