Re: MPS GC and its implications

[Andrea Corallo]

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:
>
>   >> I think you're overlooking that registers and stack are ambiguous roots.
>   >> The presence of u.s.data in a register or on the stack _prevents_ it
>   >> from moving.
>   >
>   > That doesn't resolve the difficulty, it just turns the table.  Now we
>   > could have a race condition between the Lisp thread loading a pointer
>   > into a register or pushing it onto the C stack, and the MPS thread
>   > taking a notice that the pointer is in a register or on the stack.  If
>   > the pointer was neither in a register nor on the stack when MPS
>   > started GC, it could decide to move the object, while the Lisp thread
>   > concurrently loads the pointer into a register.  So we might think the
>   > object pointed to is unmovable while it isn't.
>   >
>   > What am I missing now?
>
>   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 :)

  Andrea