On Tue, Nov 5, 2013 at 10:16 PM, Jonathan S. Shapiro <[email protected]>wrote:
> The Go story seems kind of weird. Their description of hot stacks makes it > sound like they were allocating and releasing too aggressively. I also > think the "just double the stack size" heuristic in the new scheme is > flawed, but they'll figure that out shortly. > Maybe they wont , I though double was not aggressive enough and its too aggresive for large stacks.. i was kind of shocked they still had all those stack checks in every method ( because thats what LLVM does) . Regarding the releasing i first thought the immediate releasing is an issue but the main reason for this is probably native interop , calling to C demands a large stack to provide "relative" safety .. > > 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. 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. > Yes it immediately struck me that regions are like a stack so why cant the stack be a region . The call return pattern straddling a boundary is also an issue for segmented stacks and as you said it should be easy enough for most methods to have a stack cost and if the stack cost is higher move to a new block and leave a gap. Allocating consecutive blocks ( which is really what growing the stack is ) seems promising for a number of reasons ( ensuring regions are contiguous ， to use blocks for the large object heap rather then a seperate structure) but then i question what are we doing , we are really duplicating the page mechanism and maybe just 1 block = 1..N pages becomes attractive The IBM JRockit mark -region GC used blocks of varying size they also use a vector to mark where blocks start on the line. BTW we should call these mark -block GCs not mark-region. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
