Scavenging SRTs in scavenge_one

[Simon Marlow]

Interesting point. I don't think there are any large objects with SRTs, but
we should document the invariant because we're relying on it.

Large objects can only be primitive objects, like MUT_ARR_PTRS, allocated
by the RTS, and none of these have SRTs.

We did have plans to allocate memory for large dynamic objects using
`allocate()` from compiled code, in which case we could have large objects
that could be THUNK, FUN, etc. and could have an SRT, in which case we
would need to revisit this.  You might want to take a look at Note [big
objects] in GCUtils.c, which is relevant here.

Cheers
Simon


On 20 June 2018 at 09:20, Ömer Sinan Ağacan <omeragacan at gmail.com> wrote:

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