Re: Some experience with the igc branch

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: stefankangas@gmail.com,  pipcet@protonmail.com,  ofv@wanadoo.es,
>   emacs-devel@gnu.org,  eller.helmut@gmail.com,  acorallo@gnu.org
> Date: Fri, 27 Dec 2024 19:21:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   - Concurrent.  The GC runs in its own thread.  There are no explicit
> >     calls to start GC, and Emacs doesn't have to wait for the GC to
> >     complete.
> >
> > Pip says this is not true?  I also thought MPS GC runs concurrently in
> > its own thread.
> 
> What Pip said was very easy to misunderstand, to say the least :-). No,
> MPS is concurrent, period. There are situations in which MPS can, in
> addition, use the main thread. And it's still concurrent, period.

How can you see which thread runs MPS?  Where should I put a
breakpoint to see that (IOW, what are the entry points into MPS GC
code)?  If I run Emacs with a breakpoint in process_one_message (after
enabling garbage-collection-messages), all I ever see is GC triggered
by igc_on_idle, which AFAIU is only one of the way GC can be
triggered.  Where are the entry points for the other GC triggers?  I'm
asking because I'd like to run Emacs like that and see which thread(s)
run GC.

> >   When copying objects, a marker is left in the original object pointing
> >   to its copy. This marker is also called a "tombstone". A "memory
> >   barrier" is placed on the original object. Memory barrier means the
> >   memory is read and/or write protected (e.g. with mprotect). The
> >   barrier leads to MPS being invoked when an old object is accessed.
> >   The whole process is called "object forwarding".
> >
> > This doesn't tell how object forwarding works once triggered by access
> > to protected memory.  Can you say something about that?
> > This:
> >
> >   MPS makes sure that references to old objects are updated to refer to
> >   their new addresses. Functions defined in the object format are used
> >   by MPS to perform the lowest-level tasks of object forwarding, so that
> >   MPS doesn't have to know application-specific details of how objects
> >   look like. In the end, copying/forwarding is transparent to the
> >   application.
> >
> > seems to try to explain that, but AFAIU stops short of telling it.
> > IOW, how are "functions defined in the object format used by MPS to
> > perform the lowest-level tasks of object forwarding"?
> >
> 
> I'm afraid I can't describe that in detals because it's an
> implementation details of MPS itself. AFAIK, it's not documented, and I
> don't read the sources of MPS.
> 
> Object forwarding in general is not specific to MPS. Many copying
> collectors use it. I tried to explain this as far as I could without
> knowing the MPS implementation.
> 
> Whether one should describe this in detail here is a valid question.
> Maybe someone knowing the MPS implementation in detail could add that.

I'm only interested in this insofar as it's relevant to the functions
defined in igc.c.  E.g., do any of the "scan" or "fix" function have
anything to do with object forwarding?  If so, I thought it would be
useful to describe that, to help people understand the role of those
functions and what their code needs to do.

> >   MPS allows us to specify roots having tailor-made scan functions that
> >   Emacs implements. Scanning here refers to the process of finding
> >   references in the memory area of the root, and telling MPS about the
> >   references.
> >
> > What is the purpose of "telling MPS about the references"?
> 
> If MPS were the old GC, it's like letting MPS do its mark_object.
> 
> What about if it said "... telling MPS about the reference so that it
> knows the references object is live", only expressed better?

Sure, that's much better, because it makes this much more concrete.

> > Stuff that I'd like added:
> >
> >  . a few words about the root_create_* functions
> >  . same for create_*_ap functions
> >  . why do we need the finalize_* functions?
> >  . some explanation why pdumper needs special support from igc
> >
> > Thanks again for writing this.
> 
> I'll try to add something for that. Please watch out for commits.

Thanks.