Re: MPS GC and its implications

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Helmut Eller <eller.helmut@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> Date: Sat, 04 May 2024 02:25:28 -0400
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> > Andrea Corallo <acorallo@gnu.org> writes:
> >
> >> I guess you are saying that moving does not happen in a parallel
> >> fashion, and so we'll still stop the mutator?
> >
> > Right. In a resonse to Eli I came with this explanation attempt:
> >
> >   Eli Zaretskii <eliz@gnu.org> writes:
> >
> >   Here barriers come into play. Let's say, for simplicity, that we are
> >   talking about an object on a VM page P.
> >
> >   In its thread, MPS decides that it wants to do an increment of work on
> >   P, say it wants to move objects, without the chance that MPS and client
> >   threads interfere.
> >
> >   So, MPS puts a read barrier on P (say with mprotect), so that other
> >   threads are interrupted by a signal when they read from P. MPS puts a
> >   write barrier on P so that the same happens when a thread tries to
> >   modifiy P.
> >
> >   Does that help?
> >
> > Barriers are the reason why things are done in an orderly way.
> 
> Thanks.  Will be interesting to see how often the mutator thread then is
> paused due to hitting a barrier :)

IME till now, extremely rarely.  I succeeded to trigger this only
after Helmut kindly gave me a recipe (which is a Lisp program unlikely
to happen in any real-life Lisp code), and even with that recipe, I
could hit the VM protection exception only half a dozen times in a 5
min session.

Maybe a more complex recipe, which attempts to read or write from many
more objects, could cause that more frequently, I don't know.