On Tue, Nov 5, 2013 at 6:05 AM, Jonathan S. Shapiro <[email protected]>wrote:
> Stack copying, for us, is harder. With a region system we will end up with > stack-allocated objects, and we will have references from the heap back to > those objects. Though perhaps it's no harder than any other case of object > forwarding. > Hmm. A follow-up thought here. If a stack has stack-allocated objects, and the on-stack objects have the in-heap header fields, then we can treat the location of these objects obliviously for a lot of purposes. We could copy to a new location, leave forwarding pointers from objects on the old stack, and then let the GC do it's thing to collect the old stack storage. But it strikes me that heap-allocating *frames* is a better approach than heap-allocating stack segments. Ignoring hardware optimization, the main *reason* for a stack is that it effectively provides bump allocation in conventional languages. If we introduce a new category of immix block, we can get exactly that effect in the heap. The problem is the case where you have a call/return pattern that happens to straddle a block boundary; that will turn out to be a slow-path frame construction, and it will hurt. It's not that hard to detect this case and selectively move frames across the divide, but growing the stack is probably a better solution. The idea of an immix block organization still seems interesting, though. It provides a stack map (less registers) more or less for free. Though there may be a better way to do that.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
