bug#28211: Stack marking issue in multi-threaded code

[Mark H Weaver]

Hi Andy,

Andy Wingo <address@hidden> writes:
> On Sat 30 Jun 2018 23:49, Mark H Weaver <address@hidden> writes:
>
>>>> I should say that I'm not confident that _either_ of these proposed
>>>> solutions will adequately address all of the possible problems that
>>>> could occur when GC is performed on VM threads stopped at arbitrary
>>>> points in their execution.
>>>
>>> Yeah, as discussed on IRC with Andy, we’d be better off if we were sure
>>> that each stack is marked by the thread it belongs to, in terms of data
>>> locality, and thus also in terms of being sure that vp->fp is up-to-date
>>> when the marker reads it.  It’s not something we can change now, though.
>>
>> I'm not sure it matters what thread the marking is done in, because when
>> the actual collection happens, all threads are first stopped in their
>> signal handlers, and presumably the appropriate memory barriers are
>> performed so that all threads are synchronized before the full
>> collection.
>
> I think you are right here.  Still, it would be nice from a locality
> POV if threads could mark themselves.  In some future I think it would
> be nice if threads cooperatively reached safepoints, instead of using
> the signal mechanism.  In that case we could precisely mark the most
> recent stack frame as well.

I agree that stopping threads at safepoints before collections would be
ideal.

>>> Anyway, I don’t think we’ll have the final word on all this before
>>> 2.2.4.  The way I see it we should keep working on improving it, but
>>> there are difficult choices to make, so it will probably take a bit of
>>> time.
>>
>> Sounds good.
>
> Yeah!  Really great that this is fixed, and apologies for introducing it
> in the first place!!

It's great that Ludovic found the problem (great debugging Ludovic!),
but FWIW, my assessment is that this bug is not fixed by commit
23af45e248e8e2bec99c712842bf24d6661abbe2, and therefore is not fixed in
Guile-2.2.4, contrary to the claims made in the commit log and the NEWS.
Unless I'm mistaken, that commit makes *no* difference to the
requirements on the compiler regarding the order of those writes.

        Mark