> > > > 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. >
At first i thought with 2^k you would suffer buddy equivalent fragementation but this is not the case since you can request the hole space . A bit cumbersome though so you would try to keep size common. The bump allocator is not a big deal because your counting lines the only diffirence is the # of lines but you only hit that at the end of each line ..( And you need lines to find objects quickly) , another option is when you load the block you load an allocator set to that block size ( if holding a register or variable for size is too big a cost) . > 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: > > >> >> GC header > vtable ptr > > Why do we need a GC header , every algo. works without a GC header on the stack ? Speaking of which i think the Vtable pointer can be a 32 bit pointer 1G is a LOT of type data . > 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. > > 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. > Yes Its a convenient organization for anything that wants to scan for objects. > > 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. > One of the senior rust guys gave an estimate saying it would take 12 months to put a stackmap into LLVM. I dont know LLVM that well but the basics dont seem that hard. > > >> 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. > Yes i think its better provided the header and line/metadata cost is not high . For a tightloop of calls you dont want to put down 2 words each time. Some things we can do besides reduce the header is - In a loop to the same calls we can re-use the same stack frame ( in a similar manner to callee slots if that makes sense) .. eg one thing is you can simply check if vtable pointer is the same in which case the stack frame is the same and we can just proceed to puting the variables in the slots. - If there is no references then there is no header. Such stack frames could not be easily "found" but they should not need to be and would incur zero cost . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
