Oh. I forgot a whole topic in my last: stack copying. The performance killer in a segmented stack isn't the check. It's the fact that many call sites (or equivalently, entry sites) now need to be prepared to shuffle their own frame onto a different call stack. That's both a lot of code and a lot of overhead. The only real way to avoid this is to relocate the stack.
One of the nice things about a precise stack map combined with a precise register map is that the stack can be copied. So the goal here shouldn't be stitching stack segments together. It should be *growing* the stack up to some thread-defined guard size (above which a stack overflow is really an error). Unfortunately, there may be C code on the stack. That can't be moved, because we don't know what it does. When a stack relocation occurs while C stack frames are present, what it needs to do is leave a return trampoline at the top of the new stack that returns to the C frame on the old stack. We then leave a marker at the *top* of the C frames to indicate that we should migrate the stuff *above* the C frames onto the larger stack frame when the C code has returned. Note that the call from C to managed code can arrange to always perform the code on the correct (newer and larger) stack. Also note that during the "copy on return from C" code, the new stack region is known to be completely empty, just as it was when we did the earlier stack relocation. Offhand, I provisionally believe that whenever a stack relocation occurs, it is always the case that frames are being migrated into an empty chunk. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
