Scavenging SRTs in scavenge_one

[Ömer Sinan Ağacan]

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 <omeragacan at 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 <marlowsd at 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 <omeragacan at 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 <ben at 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 at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >> >
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >