Re: MPS GC and its implications

[Helmut Eller <eller.helmut@gmail.com>]

>> I'm not sure what is with the buffer case, but the string case means
>> that source can point to string data, which is in our MPS leaf_pool. I
>> think we cvould use an exact scan function for that purpose, analogous
>> to scan_specpdl. WSYT?
>
> If this is indeed needed, we are in trouble.  When we take a C pointer
> to buffer or string text and use it in the following code, it's
> because there's a hidden assumption that GC cannot happen during the
> time the C pointer is being used.  If this assumption is not true with
> MPS, nothing in Emacs will work reliably.
>
> Is this indeed a problem?  Didn't Gerd just explain to Andrea that
> every object referenced from the stack or even from a register will be
> automatically "fixed" if GC happens and decides to move the objects?
> If so, why doesn't that solve the problem here?

The stack and registers are ambiguous roots.  The objects they point to
are "pinned" i.e. not allowed to move.  So as long as we keep a pointer
in a local variable, things should work out fine.

For references in global variables, we can decide to make them exact or
ambiguous.  If we make them exact, we have to be very careful.

> More generally, what happens with text of Emacs buffers and strings
> when GC runs?  I know what the old GC did, but what does the new GC
> do?

If we only have exact references to those, then they can be moved.

> A related question, no less important, is: when can MPS GC happen, and
> whether there's any reasonable way of being sure that it cannot
> possibly happen while certain code fragments run?

Would be nice to handle one catastrophe at the time :-)

> For example, the
> old GC could only be triggered by a call to funcall or eval (and a
> small number of similar APIs); as long as the C code didn't cause any
> of these calls, we could assume GC will not happen, and so any C
> pointers to Lisp objects were safe to use.  What is the equivalent of
> that with MPS?  Since MPS is a moving GC, this becomes much more
> important; with old GC we only had 2 object types that could move
> during GC: string data and buffer text.  Now every Lisp object is in
> danger of being moved by GC, AFAIU.
>
> Am I missing something?

I think MPS is a concurrent GC, it means it runs "all the time".  The
reason why his works are the memory barriers.  But maybe Gerd knows how
things actually work.

Helmut