Thanks Simon, this is really helpful. > If you look at scavenge_fun_srt() and co, you'll see that they return > immediately if !major_gc.
Thanks for pointing this out -- I didn't realize it's returning early when !major_gc and this caused a lot of confusion. Now everything makes sense. I'll add a note for scavenging SRTs and refer to it in relevant code and submit a diff. Ömer 2018-05-01 22:10 GMT+03:00 Simon Marlow <marlo...@gmail.com>: > Your explanation is basically right. scavenge_one() is only used for a > non-major collection, where we aren't traversing SRTs. Admittedly this is a > subtle point that could almost certainly be documented better, I probably > just overlooked it. > > More inline: > > On 1 May 2018 at 10:26, Ömer Sinan Ağacan <omeraga...@gmail.com> wrote: >> >> I have an idea but it doesn't explain everything; >> >> SRTs are used to collect CAFs, and CAFs are always added to the oldest >> generation's mut_list when allocated [1]. >> >> When we're scavenging a mut_list we know we're not doing a major GC, and >> because mut_list of oldest generation has all the newly allocated CAFs, >> which >> will be scavenged anyway, no need to scavenge SRTs for those. >> >> Also, static objects are always evacuated to the oldest gen [2], so any >> CAFs >> that are alive but not in the mut_list of the oldest gen will stay alive >> after >> a non-major GC, again no need to scavenge SRTs to keep these alive. >> >> This also explains why it's OK to not collect static objects (and not >> treat >> them as roots) in non-major GCs. >> >> However this doesn't explain >> >> - Why it's OK to scavenge large objects with scavenge_one(). > > > I don't understand - perhaps you could elaborate on why you think it might > not be OK? Large objects are treated exactly the same as small objects with > respect to their lifetimes. > >> >> - Why we scavenge SRTs in non-major collections in other places (e.g. >> scavenge_block()). > > > If you look at scavenge_fun_srt() and co, you'll see that they return > immediately if !major_gc. > >> >> Simon, could you say a few words about this? > > > Was that enough words? I have more if necessary :) > > Cheers > Simon > > >> >> >> [1]: https://github.com/ghc/ghc/blob/master/rts/sm/Storage.c#L445-L449 >> [2]: https://github.com/ghc/ghc/blob/master/rts/sm/Scav.c#L1761-L1763 >> >> Ömer >> >> 2018-03-28 17:49 GMT+03:00 Ben Gamari <b...@well-typed.com>: >> > Hi Simon, >> > >> > I'm a bit confused by scavenge_one; namely it doesn't scavenge SRTs. It >> > appears that it is primarily used for remembered set entries but it's >> > not at all clear why this means that we can safely ignore SRTs (e.g. in >> > the FUN and THUNK cases). >> > >> > Can you shed some light on this? >> > >> > Cheers, >> > >> > - Ben >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs