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 <m...@netris.org> 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
