On Wed, Aug 7, 2013 at 7:29 PM, David Jeske <[email protected]> wrote:
> Actually, I was saying that I think the reason we see more expensive throw > is because they are preserving stack-frame-info before it's destroyed. I > think this might be a harder problem than you're suggesting... > I *think* the conversion only occurs when a breakpoint is encountered. If that break point is in a catch handler somewhere, and you've already traversed from the point of throw into that catch handler, the stack frames between the throw and the handler are already gone forever. The only way to get a stack backtrace at the point of raise is to actually put a breakpoint on the primitive _raise (I think that's the name) function. > The top-level handler definitely wants a stack backtrace, but you don't > know whether you're going to hit the top-level handler or not.. > Oh! Finally the light dawns on my marble head. Yes. It all comes back to me now. I'm completely wrong about the stack reconstruction. The need to report the trace forces a full stack reconstruction at the moment of throw. But the right fix is not to do that stack trace reporting! It's a bad idea in any case. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
