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

[Andy Wingo]

Hi!

First of all, I said on IRC but: ___nice___ debugging, Ludo!  An
impressive show of persistence.  Thanks Mark also for insightful
comments!

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.

>> 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!!

A