re overthinking.. I really dont think davids performance requirements is feasible eg less than 10* non exception cost for trivial work and to have a proper stack trace for release. And by proper i mean Method / assembly names in the trace - thats so helpful for resolving production bugs ( i really dont want to go back to rememebering hex address offsets of methods ..) . ..
You have a cost where you dont throw the exception and have cheaper exceptions but i dont think thats acceptable. The work on .NET on a throw is clear Create a new Exception object ( there is your 10* cost already + branch miss , cache misses from the following etc ) copy methods from the stack to Exception object ( or whole stack ) load / copy map of address to method name.* change stack to strings now ( or in global handler) unwind stack till a catch handler is found * i think this map is harder with CLR type assemblies then DLLs , they dont get unloaded but getting a map of release code may not be easy , the jit generates them sequentially as seen.. .. Even for native what happens if the dll is unloaded later... your back to a hex stack trace. Williams solution where you want a special exception ( or my if ) and you dont copy the stack etc could be helpful for the validation type cases. eg NoStackExcption as the base class for validation. As it hapens in the construction of the throw Exception object there should be no issue with finalize. Ben On Fri, Aug 9, 2013 at 10:56 AM, William ML Leslie < [email protected]> wrote: > On 9 August 2013 12:35, William ML Leslie <[email protected]> > wrote: > > On 9 August 2013 11:48, Jonathan S. Shapiro <[email protected]> wrote: > >> That's to strong. First, the backtrace printing mechanism isn't done in > a > >> handler. It's done deep in the runtime. Second, it's perfectly fine for > >> unwind code to change the stack pointer. All we need to do to support > the > >> backtrace is to save the stack pointer that was current at the time of > the > >> most recent exception on that thread. > > > > That doesn't seem sufficient, because all of the stack above the frame > > of the handler can be overwritten by the handler. A pointer into > > space that is available for allocation is not useful. > > I guess that if you really want the traceback, we could make you > declare your intent in the handler. > > try: > party_time() > # Extended except form declares that it wants a traceback, > # which will be generated if not provided. > # not saying anything about who can create values of type > # TraceBack. > except (e : OutOfBeer, tb : TraceBack): > logger.exception("Party ran dry", tb) > # extended raise form means no traceback needs to be > # generated if the next handler wants one > # not sure if I want the caller to be able to lie, but oh well > raise e, tb > > -- > William Leslie > > Notice: > Likely much of this email is, by the nature of copyright, covered > under copyright law. You absolutely may reproduce any part of it in > accordance with the copyright law of the nation you are reading this > in. Any attempt to deny you those rights would be illegal without > prior contractual agreement. > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
