Re: MPS GC and its implications

[Helmut Eller]

On Fri, May 03 2024, Eli Zaretskii wrote:

> I think this still leaves something unclear, at least to me.
>
> Let's say some Lisp thread in Emacs is running, and MPS decides to
> perform GC.  AFAIU, the GC will run in a separate thread, right?  So
> the question that bugs me is how does the GC thread and the Lisp
> thread synchronize so as to prevent the situation where GC moves an
> object in-between two accesses to the object by the Lisp thread?  If
> the Lisp thread is stopped while GC runs, the answer is clear.  But if
> the Lisp thread continues running concurrently with GC, I don't
> understand how this could possibly work, especially on a modern CPU
> with N > 1 execution units.  In particular, how does MPS handle the
> time window between moving an object and updating all the references
> to the object, so that once an object is moved, all accesses to the
> object are redirected to the new location?  If nothing is done, it is
> possible that a Lisp thread accesses the old address which is no
> longer valid, because the object was moved between the time the Lisp
> thread loaded the address into a register and the time it uses the
> address to access the object, but the address in the register was not
> yet updated.
>
> What am I missing?

Memory barriers could be used for synchronization.  When the mutator
hits a barrier, it executes the signal handler.  The signal handler asks
the collector what to do.  Essentially synchronizing those two.

I don't know if MPS works quite like this, but it could.  I'm not
worried about this issue.