Maybe I should explain how I think forwarding should work. First, I assume that object relocation is performed by the collector. Each object is copied to a new location in a new block. The target block is owned by the collector, and allocations within that block are thread local to the collector. In this approach we accept the assumptions of RC-immix, notably that no mutator executes during collection. Therefore we are only concerned with races from other collectors.
Basically, the collector first checks the (singleton) F bit to see if the object has been moved. If not, it makes an optimistic copy. No mutator is running, so no changes to the object will occur other than header changes made by other collector threads. After copying the object, the collector thread attempts to set the F bit using compare and swap. The remaining bits of the header store the forwarding pointer (credit: O'Toole and Nettles). If the swap succeeds, the object has been forwarded. If the cswap fails, then some other collector thread was performing the forward simultaneously and finished first. In the latter case we zero out the failed optimistic copy and restore the bump allocation pointer to its base. The window of collision can be further narrowed if we do the cswap immediately after migrating the first header word. The F bit being one signals other collector threads to steer clear. So far as I can tell, this approach requires only one bit to record forwarding while preserving concurrent collection. Issues? Shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
