On Fri, Oct 25, 2013 at 11:38 AM, Sandro Magi <[email protected]>wrote:
> Couldn't you just just allocate unboxed references into a stack-scoped > region, instead of directly on the stack? This should restore > incrementality and seems a good middle ground between stack and heap > allocation. I don't think so. Semantically, what you say works. The problem is that a sufficiently big array may take a long time to trace, and the frame may exit before tracing completes. To put it in terms of the tri-color abstraction: you can move a large object from white to grey in just a few instructions, but getting from grey to black can take a while. The problem is that you may be running the collector inside that region (i.e. concurrently) when the region goes out of scope. You can't release the region while it still contains grey objects, because the collector may be accessing the region concurrently. If your scheme maintains the *strong* tri-color invariant, you know that all objects in the region are non-live, and you can therefore transition grey objects in the stack-scoped region to black without further scanning. But if your system only maintains the *weak* tri-color invariant, you need to let the scan complete. Unless the stack-scoped region is somehow partitioned from the rest of the heap in an identifiable way, you're going to have a hard time reclaiming that storage quickly. I see how to do it; it just isn't pretty. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
