Why not short out IND_STATICs in the GC?

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? Thanks, Ömer

On Sat, 27 Apr 2019 at 07:44, Ömer Sinan Ağacan
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
participants (2)
-
Simon Marlow
-
Ömer Sinan Ağacan