On Thu, Nov 7, 2013 at 6:39 PM, Ben Kloosterman <[email protected]> wrote:
> You mentioned for a stack placed in an Immix style block heap we would > get a stack map for ( amost? ) free . > Yes. I'm not sure that was a good way to describe it. Let me try to "unpack" what's going on in my head here. First, everybody talks about three allocators (nursery, tenured, LOS), but they forget to talk about the fourth allocator: the one that manages virtual address regions. The reason this matters is that there are various "extra" data structures outside the heap that we would like to allocate from a common framework. The stack is one such. Dynamically loaded assemblies are another. If nothing else, we'd like some control over where these things go so that we can keep the primary heap contiguous. Second, there is nothing magical about a particular fixed-size immix block. We can generalize the notion to any 2^k byte block above some minimum size. The only reason we want to know the size statically is that it reduces the number of instructions in the bump allocator fast path. But the *structure* of the immix block has some advantages. Mainly: (1) it provides a common data structure against which allocation can occur, and (2) it lets us readily find the beginnings of objects for marking purposes. So how does this relate to the stack? You wrote: > Stacks value objects normally dont have headers nor do reference > variables. I think these are the only things we are interested in. > That's correct. But suppose we take the view that a stack is a degenerate immix "free" block. In this view, every stack frame on the stack would begin with a GC header word and a vtable pointer slot. We're obviously not going to have a vtable for a stack frame, but the vtable is really the per-type structure. So what's really going on here is that we're assigning an object type for each possible stack frame. More precisely: we're going to interleave an object-like structure onto the stack at each procedure call, which looks like: GC header vtable ptr caller saved values return PC ---- < SP at procedure entry points here saved SP callee local slots And if the stack lives within an immix-like region, then we get bits written into the immix metadata that tell us where the beginning of each frame is. Here's what's cute about this: 1. We construct a per-procedure vTable structure. We obviously don't have virtual calls on procedures themselves, but the vTable holds (or references) the information needed to mark the object. So the action needed to mark a frame is simply to call mark-object(). 2. The funny choice of overlay eliminates the need to have *multiple* vtables per procedure, because downward arguments go in the "next" object. 3. If, for some reason, we wanted the stack to actually be a chain of objects, this isn't a bad organization. But mainly, what I was trying to say was that stacks are allocated from blocks, and there are ways we can exploit the immix-style block organization that are useful for stack marking. Also why is it so hard the LLVM quote was 12 months , the basics seem > trivial . this is always a dangerous thing to say but that means im > missing something. > I'm not sure what LLVM quote you are referring to. > eg put a map frame down every 4K . > When you put a reference on the stack ( local var or paramater) , shift to > get the page and mark the reference as a bit in the frame. > When you put a value object copy the vector from the type. > + Need to handle a stack array > Yeah, that would work, but I think the approach I'm sketching is simpler and does a better job of reusing mechanism. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
