Scavenging SRTs in scavenge_one

[Ömer Sinan Ağacan]

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().

- Why we scavenge SRTs in non-major collections in other places (e.g.
  scavenge_block()).

Simon, could you say a few words about this?

[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
>