Why not short out IND_STATICs in the GC?

[Simon Marlow]

On Sat, 27 Apr 2019 at 07:44, Ömer Sinan Ağacan <omeragacan at gmail.com>
wrote:

> Hi Simon,
>
> I'm wondering why in the GC we don't short out IND_STATICs like we do in
> INDs
> and BLACKHOLEs. Is there a reason for that? In this code in evacuate():
>
>       case IND_STATIC:
>           evacuate_static_object(IND_STATIC_LINK((StgClosure *)q), q);
>           return;
>
> Why not do something like
>
>       case IND_STATIC:
>           q = ((StgIndStatic*)q)->indirectee;
>           *p = q;
>           goto loop;
>
> I actually tried it and it broke a lot of things, but I don't understand
> why.
> We basically turn this
>
>     heap closure -> IND_STATIC -> heap closure
>
> into
>
>     heap closure -> heap closure
>
> To me this should work, but for some reason it doesn't. Could you comment
> on why
> this doesn't work?
>

I think it might be to do with generational GC, although I'm not completely
sure and it would be good to nail down the precise reasoning and document
it.

CAFs live in the old generation, and when we first enter a CAF we add it to
the mutable list (remembered set). If we ignore the IND_STATIC, then the
closure will never get re-added to the mutable list, even if it still
points into the young generation. So the data will remain live for one GC,
but not the next GC. When we do an old-generation GC we might find the CAF
to be live (via the SRTs), but we've already GC'd the value it pointed to,
so it's too late.

Cheers
Simon

>
>
> Thanks,
>
> Ömer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190429/4c6a1c1d/attachment.html>