Scavenging SRTs in scavenge_one

[Simon Marlow]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180501/1ffcaa64/attachment.html>