On Wed, Aug 7, 2013 at 5:16 PM, David Jeske <dav...@gmail.com> wrote:
> > On Aug 7, 2013 1:33 PM, "Jonathan S. Shapiro" <s...@eros-os.org> wrote: > > Why on earth would you ever be copying the stack? > > What scope should the stack backtrace be valid for? Once a finally block > runs (potentially calling a function), the stack is modified so the > original stack has been overwritten. > I feel like I managed to miss a complete sub-discussion, and I'm flailing in the ocean a bit here. Yes, the finally block runs, potentially modifying the stack. So what? Why does perfectly normal execution cause us to want to copy the stack here? I think I'm missing the problem you are trying to solve that is prompting you to want to save the stack. > In practice, I've had even more trouble with the performance of CLR > exceptions while running under a debugger. Even when the exceptions are > caught, they put a massive toll on performance. This seems implementation > defined and fixable. > Yes. What I'm about to say is three parts fuzzy memory and seven parts speculation, but here's what I *think* is going on: The catch block back-chain is embedded in the normal stack, but should really be thought of as a side stack. When an exception is raised, it follows the code in the chained catch handlers. In a certain sense, this code is "out of band" w.r.t. the main code. Also, there are various ways in which this code runs in stack frames that violate the CLR type system. For example you can be in states where values on the stack don't look right. When you put a debugger into this picture, all of that cheating has to be made right. The proper state of the stack frame needs to be reconstructed so that the debugger can look at it. My dim recollection is that CLR's policy is to re-create a valid stack state as soon as a debugger stop occurs, rather than wait for the frame to be examined. > Bennie, all I want is a fast structured error handling mechanism which > includes assignment analysis. I don't much care is there is another slow > one. I'm happy to ignore it. > Can you say what you mean by "assignment analysis" here? > The issue I have with slow exception handling is that it generally forces > me into choosing between fast less-safe code with no assignment analysis; > or slow safer code with exceptions. That's a bad deal in my book. > Fair enough. But you're asserting very general conclusions about exception handling performance on the basis of the poor performance of a single, questionable implementation (CLR). I think there's another question to ask here. Is the CLR's approach to exception handling the real culprit here, or is the real problem the fact that dynamic introspection exists in CLR? shap
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
