Re: Write barrier for stack updates?
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 , 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 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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Write barrier for stack updates?
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 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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Write barrier for stack updates?
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 ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
