On Tue, Nov 19, 2013 at 10:20 PM, Ben Kloosterman <[email protected]>wrote:
> I put the stack comments here > Thanks! > Im firmly in the 1 big stack and tune it down camp ( its simple ,known and > is the status quo) and add growable stacks as a feature. > I agree. I felt it was worth understanding what copying the stack would entail, but I think this is the right place to start. I do think that different activities have different stack size requirements, so I want that to be something you can say at thread allocation time, but I don't even think saying *that* needs to be doable in the default thread creation call. > The real issue is that in an optimizing implementation, you may end up >> with multiple stack maps for a single frame, because locations on the stack >> may be used for integers at one moment and object references the next. You >> already need some sort of lookup of the form (base PC, bound PC, stack map >> addr), but you'll get a lot more entries if the shape of the frame is >> changing. >> > > Wouldnt it be better to burn the stack memory and reserve slots for each > potential use ? Variable size stacks dont mix well with Immix Blocks and > method metadata. > All stacks are variable size. You're talking about variable frame size. In the presence of alloca or general stack allocation, a variable frame size is unavoidable. As I've noted elsewhere, I was never contemplating treating frames as immix-allocated objects. I was only contemplating using the immix block layout for certain purposes of convenience. And I think we've concluded that it probably isn't worth it. All that being said, you may be right, and it may be that every stack frame should be strongly partitioned along the lines you suggest. The problem case is going to arise when a single procedure first has a loop manipulating a larger object in sequence (that does not survive the loop) and then has a second loop doing integer-only computation. We'll end up paying the stack space for that object after we are done with it. This is an observed problem in C compilers (where objects are not a consideration), which is why many of those compilers do interference analysis on locals to try to shrink the stack frame sizes. It will be greatly exacerbated by aggressive stack allocation. So: what you propose is the right place to start, but it's an optimization we probably need to address long term. > Also the Metadata map would need to be made after inlining which is quite > low level. > Definitely. And that's why all of the intermediate transformations along the way need to maintain a distinction between object referencing SSA registers and value-only SSA registers. > ...what i dont get ( and which maybe misleading me ) was in the paper > mentioned before how size analysis of the worst case stack path > significantly reduced the cost... > Remember that they were allocating segments dynamically without benefit of a guard page, so in the absence of interprocedural analysis every procedure had to do a painful check in the preamble. The interprocedural analysis lets them clone procedures into checking and non-checking implementations, and then roll up the depth checks into a single dominating location. Think of it as an optimization to the calling convention for leaf procedures, but extending the notion of "leaf" to cover more than one layer. > Badly behaved C is a pain but you are right you can leave the old stack > there and handle it , at the cost of wasting memory . > Usually temporarily, because it's rare for C code to call back into the managed subsystem. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
