Ah, this makes so much sense, thanks. I was looking at call sites of recordMutable, recordMutableCap etc. and forgot about recordClosureMutated which is apparently what dirty_STACK calls.
Thanks, Ömer Simon Marlow <[email protected]>, 18 Tem 2018 Çar, 10:52 tarihinde şunu yazdı: > > Hi Ömer, > > The write barrier is the function `dirty_STACK()` here: > https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2Fsm%2FStorage.c$1133-1140 > > If you grep for `dirty_STACK` you'll see it being called everywhere we mutate > a STACK, in particular in the scheduler just before running a thread: > https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2FSchedule.c$412 > > We don't call the write barrier in the code generator or from primops, > because at that point the thread is already running and has already been > marked dirty. If we GC and mark the stack clean, then it will be marked dirty > again by the scheduler before we start running it. > > Cheers > Simon > > On 17 July 2018 at 20:45, Ömer Sinan Ağacan <[email protected]> wrote: >> >> Hi Simon, >> >> I'm a bit confused about stack updates in generated code and write barriers. >> Because stacks are mutable (we push new stuff or maybe even update existing >> frames?) it seems to me that we need one these two, similar to other mutable >> objects: >> >> - Always keep all stacks in mut_lists >> - Add write barriers before updates >> >> However looking at some of the primops like catch# and the code generator >> that >> generates code that pushes update frames I can't see any write barriers and >> the >> GC doesn't always add stacks to mut_lists (unlike e.g. MUT_ARR_PTRS). I also >> thought maybe we add a stack to a mut_list when we switch to the TSO that >> owns >> it or we park the TSO, but I don't see anything relevant in Schedule.c or >> ThreadPaused.c. So I'm lost. Could you say a few words about how we deal with >> mutated stacks in the GC, so that if an old stack points to a young object we >> don't collect the young object in a minor GC? >> >> Thanks, >> >> Ömer > > _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
