Scavenging SRTs in scavenge_one
marlowsd at gmail.com
Tue May 1 19:10:04 UTC 2018
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.
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 .
> 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,
> will be scavenged anyway, no need to scavenge SRTs for those.
> Also, static objects are always evacuated to the oldest gen , so any
> that are alive but not in the mut_list of the oldest gen will stay alive
> 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.
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 :)
> : https://github.com/ghc/ghc/blob/master/rts/sm/Storage.c#L445-L449
> : https://github.com/ghc/ghc/blob/master/rts/sm/Scav.c#L1761-L1763
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs