Keep in mind that I'm still working on the URC paper, so maybe there are better answers there that I don't know about yet. :-)
One aspect of RC-immix that seems though-provoking is that it can act as a hybrid collector. If you have a batch of objects that you know are going to be released in bulk, it would be very possible to do something like: Region rgn = NoRCRegion(); let x = new(rgn) Foo in ... build graph here ... ... x live here ... ... x later dies ... A "NoRCRegion" is one in which all reference counts are set on allocation to MaxCount. It exploits the sticky count property to guarantee that objects allocated from this region will *only* be freed by the background collector. The membrane here is very permeable; references pointing *in* to the region behave normally, and references pointing *out* of the region behave normally. The only problem is that you aren't going to get any of this storage back in any kind of hurry (except in the generational GC sense). But I can't help but wonder if there might be a way to explicitly identify (at the source level) objects having the property that every in-bound pointer to the object is either (a) a root pointer, or (b) a pointer field of an object in the same allocation region. The goal is to deal with large data structures that die as a group *without* requiring a full-heap GC. So the idea is that: - References pointing across regions are counted. - Objects whose in-bound references are statically known to be "same region" are handled by mark-sweep - Collections on such a region may be invoked explicitly if desired. The collection is done by a marking collector, and need only consider as roots those objects in the region that have non-zero reference counts. In fact, now that I think about it, I wonder if there isn't a generalization of this for intra-block references. Suspect I need to go read some more GC papers. Oh. Hmm. This doesn't seem hard at all, now that I'm thinking about it. Not sure there is room for the necessary bits in the object header, but it would lower the reference counting overhead a lot and reduce the mark/sweep phases to single blocks that can be done very incrementally in the background. It would also kill off a lot of small cycles early (those that don't cross block boundaries), and provide a naturally nested cycle detection algorithm for the remainder (because object cycles are only possible within block cycles). Maybe it's time for me to stop pondering stuff like this out loud before I know if it's worth anybody's time. :-) OK. Back to the URC paper for me. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
