Scavenging SRTs in scavenge_one

Ömer Sinan Ağacan omeragacan at gmail.com
Wed May 2 06:03:05 UTC 2018


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


More information about the ghc-devs mailing list