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
