On Fri, Nov 22, 2013 at 10:28 AM, Jonathan S. Shapiro <[email protected]>wrote:
> For those "stuck" objects, I'd really like to know what the in-degree is, > and I'd like some sense of how read-hot the containing blocks are once the > other 90% of the objects are gone. That would tell us if a "mostly not > copying" design is feasible. > That was important, and much too elided. Let me unpack it. If the last 10% of objects in a block have low in-degree (i.e. the refcount hasn't hit "top"), and it isn't *write* hot (I said read-hot above, but that's a mistake), then we can relocate the objects *even* in a collector that is otherwise non-relocating. Here's how: 1. At start of GC, we take note of the blocks we would like to clear. We *read and write protect* these blocks if the mutator is concurrent, mirroring at some other address so that relocation can proceed. 2. As we rebuild reference counts, we keep track of the slots containing pointers into evacuating blocks. 3. We forward the objects to new locations. 4. We patch the locations containing in-bound pointers. What's left is copies that may have been made by the mutators. 5. Halt each mutator in turn long enough to forward it's current frame, install a stack barrier, and collect the nursery, forwarding references as we go. This flushes the RC deferred update table, which has the side effect of forwarding any pointers to the old location that may have been stored to tenured space since we forwarded the object. 6. Resume that mutator. Hmm. No, that's not quite it, because a reference could bounce back and forth between two CPUs via the heap and this won't necessarily catch that case. Darn. I really hate to put a forwarding check in the store barrier... OK. I don't have it yet.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
