Re: Some experience with the igc branch

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com,  ofv@wanadoo.es,  emacs-devel@gnu.org,
>  eller.helmut@gmail.com,  acorallo@gnu.org
> Date: Wed, 25 Dec 2024 13:50:37 +0100
> 
> >   . how is accessing F different from accessing the specpdl stack?
> 
> F's memory is allocated from an MPS pool via alloc_impl in igc.c. Most
> objects are allocated from a pool that uses barriers (I think except
> PVEC_THREAD). The specpdl stacks are mallocs (see
> grow_specpdl_allocation), and uses as a roots. There are currently no
> barriers on roots.

So you are saying that the answer to this:

> > The first question is more important, from where I stand.  Looking
> > forward beyond the point where we land igc on master, I wonder how
> > will be able to tell, for a random non-trivial change on the C level,
> > whether what it does can cause trouble with MPS?  That is, how can a
> > mere mortal determine whether a given data structure in igc Emacs can
> > or cannot be safely touched when MPS happens to do its thing, whether
> > synchronously or asynchronously?  We must have some reasonably
> > practical way of telling this, or else we will be breaking Emacs high
> > and low.

is that we need to trace each datum to see whether it is "used as
roots" (what does that mean in practice, btw?) or is "allocated via
alloc_impl in igc.c"?  Does the latter include all the Lisp objects
(except fixnums)?  Do we allocate non-Lisp data via alloc_impl, and if
so, which data?

Once again, I think this is very important for future maintenance.  I
feel that this barrier thing in MPS introduces significant
complications into reasoning about safety of C-level changes.
Previously, we only had the mark bit to worry about if we wanted to
access Lisp objects during GC (see gc_asize, for example), but now we
have a much larger problem, AFAIU.  How do we manage that for the next
40 years?