Re: MPS GC and its implications

[Gerd Möllmann]

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.