<div dir="ltr">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.<br><div class="gmail_extra"><br></div><div class="gmail_extra">More inline:<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 May 2018 at 10:26, Ömer Sinan Ağacan <span dir="ltr"><<a href="mailto:omeragacan@gmail.com" target="_blank">omeragacan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have an idea but it doesn't explain everything;<br>
<br>
SRTs are used to collect CAFs, and CAFs are always added to the oldest<br>
generation's mut_list when allocated [1].<br>
<br>
When we're scavenging a mut_list we know we're not doing a major GC, and<br>
because mut_list of oldest generation has all the newly allocated CAFs, which<br>
will be scavenged anyway, no need to scavenge SRTs for those.<br>
<br>
Also, static objects are always evacuated to the oldest gen [2], so any CAFs<br>
that are alive but not in the mut_list of the oldest gen will stay alive after<br>
a non-major GC, again no need to scavenge SRTs to keep these alive.<br>
<br>
This also explains why it's OK to not collect static objects (and not treat<br>
them as roots) in non-major GCs.<br>
<br>
However this doesn't explain<br>
<br>
- Why it's OK to scavenge large objects with scavenge_one().<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Why we scavenge SRTs in non-major collections in other places (e.g.<br>
  scavenge_block()).<br></blockquote><div><br></div><div>If you look at scavenge_fun_srt() and co, you'll see that they return immediately if !major_gc.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Simon, could you say a few words about this?<br></blockquote><div><br></div><div>Was that enough words? I have more if necessary :)<br><br></div><div>Cheers<br></div><div>Simon<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1]: <a href="https://github.com/ghc/ghc/blob/master/rts/sm/Storage.c#L445-L449" rel="noreferrer" target="_blank">https://github.com/ghc/ghc/<wbr>blob/master/rts/sm/Storage.c#<wbr>L445-L449</a><br>
[2]: <a href="https://github.com/ghc/ghc/blob/master/rts/sm/Scav.c#L1761-L1763" rel="noreferrer" target="_blank">https://github.com/ghc/ghc/<wbr>blob/master/rts/sm/Scav.c#<wbr>L1761-L1763</a><br>
<br>
Ömer<br>
<div><div class="h5"><br>
2018-03-28 17:49 GMT+03:00 Ben Gamari <<a href="mailto:ben@well-typed.com">ben@well-typed.com</a>>:<br>
> Hi Simon,<br>
><br>
> I'm a bit confused by scavenge_one; namely it doesn't scavenge SRTs. It<br>
> appears that it is primarily used for remembered set entries but it's<br>
> not at all clear why this means that we can safely ignore SRTs (e.g. in<br>
> the FUN and THUNK cases).<br>
><br>
> Can you shed some light on this?<br>
><br>
> Cheers,<br>
><br>
> - Ben<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
><br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br></div></div>