On Mon, Apr 21, 2008 at 04:31:17PM -0400, Bob Rogers wrote: > From: "Patrick R. Michaud" <[EMAIL PROTECTED]> > Date: Mon, 21 Apr 2008 14:55:21 -0500 > > > On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud <[EMAIL PROTECTED]> > wrote: > > > I think we'd get a BIG win if we changed the dynamic_env stack to > > > have an approach similar to ResizableIntegerArray, where we allocate > > > arrays of Stack_Chunk entries and manage them that way, instead of > > > a separate allocation per element in the stack. > > That would make the implementation of the continuation classes > unnecessarily difficult. These classes need to be able to point to > individual dynamic_env entries in order to restore the dynamic > environment precisely. Using arrays opens the possibility of > overwriting slots, which would destroy dynamic state that some > continuation may depend upon. (And if slots are *not* overwritten, then > you probably lose the benefit of the optimization.)
Thanks for this very useful note. I'll keep it in mind as we go. > Don't forget the other dynamic_env uses for error handling, actions, and > marks. A lot of simplification would indeed be possible, but even then > it would not be "just a stack of addresses." Hadn't forgotten them -- just still learning about the problem. > There is another solution that ought to speed up "bsr" dramatically: > Give the "bsr" return addresses their own stack. I thought of this also, but given that they share a stack currently I figured the smaller delta would be to keep it that way. If it looks like having a separate stack for bsr/ret is workable then I'll go at it that way. But the first step is eliminating the user stack, and I've started on that now in the 'stacks' branch of the svn repo. Pm
