> > If performance has to halve in order to implement such features, I hope > > somebody plans to write Parrot::Lite! > > I'm not sure if I understand the problem properly, but is the problem with > using exceptions (or using longjmp) and the like to unwind that we can't > trust external extensions to play ball with our rules when we need to unwind > through them? And that if we didn't have to call out to external code, we > could use the faster methods without needing stack walking?
Well, I only knew about the first problem, but I suppose the "external code" problem is another valid one. :) > If so, is it possible to make a hybrid scheme, whereby if we know that > between the two marks on the stack we've not called out to any external > code we use the faster mechanism to check for leaks, but if we know that > we entered external code (and must have come back in because we're now back > in the parrot garbage collection system called by another parrot call) use > a tack walk. Obviously we'd carry the overhead of more bookkeeping, but it > might win if it saves the stackwalk. (and thrashing the cache in the process) I do like this idea, although we'll have to run it by Dan first. I know that both Peter and I had different solutions to the pointers-on-the-stack problem, and all such ones were rejected. I'd have to do benchmarks comparing my own (neonate buffers) to the current stackwalk code, but I'm sure both Peters and mine would win, hands down. That's mainly because we: a) don't call external code b) don't use longjmp So our solutions, and the bookkeeping they entail, would never be wasted, because there is nothing to invalidate them yet. To really determine their worth, we need real-world programs, and figure out how often would they be using longjmp, and external code, to determine how often the bookkeeping is wasted. But that brings me back around to the point in my previous email, about the mythical "real world program". :) Mike Lambert
