Hi Simon, I'm confused about this code again. You said
> scavenge_one() is only used for a non-major collection, where we aren't > traversing SRTs. But I think this is not true; scavenge_one() is also used to scavenge large objects (in scavenge_large()), which are scavenged even in major GCs. So it seems like we never really scavenge SRTs of large objects. This doesn't look right to me. Am I missing anything? Can large objects not refer to static objects? Thanks Ömer Ömer Sinan Ağacan <omeraga...@gmail.com>, 2 May 2018 Çar, 09:03 tarihinde şunu yazdı: > > 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
