On Fri, Oct 14, 2011 at 7:24 PM, Tom Rodriguez <tom.rodrig...@oracle.com> wrote: > Are you expecting some performance penalty from doing this? Generally > speaking if you are throwing exceptions at all then you've already lost a > bunch of performance. The lookups and unwinding are probably negligible in > the general case.
Ok, that was my concern. It "felt" like the shape of a single handler that type-checks would be considerably worse than explicit catches, but as you describe below that's probably not the case. > If the exception is thrown from a callee, out of sight of the current > compilation, then the only thing that's used for deciding where to dispatch > is the exception handler table in the method. There JIT isn't even involved > in that case until the exception reaches the current nmethod. Take a look at > exception_handler_for_return_address, which finds the PC to dispatch to in > the caller frame. > > So in your case you might jump to the exception handler, do the type check > and then simply unwind as you would have before. C2 does something similar > to what you've done when dispatching exceptions. A single try with multiple > catches sends all exceptions to a single entry point in the compiled code > which then type checks them and dispatches to the right location, as you've > done. catch_inline_exceptions in doCall.cpp does this. C1 relies on the > exception handler table and dispatches them individually, with a separate > entry point for each type mentioned in a catch. For locally thrown and > caught exceptions C2 maybe convert that directly into control flow and > possibly simplify type checks along the way. C1 still goes the long route. > > So basically I would be surprised if doing what you're doing would hurt the > speed of throwing and catching exceptions by a measurable amount in real > programs. Ok, that's reassuring. Again we're also talking about performance when an exception *does* happen, which as you point out is already going to be a hit (backtrace generation, unwinding). > Where it might hurt you is with compiled code complexity, assuming that you > are spreading your try/catch over large blocks of code that might not really > need handlers. Remember that every exception handler creates extra control > flow edges which can complicate code generation. This is very hard to > quantify and may or may not matter but it seemed worth mentioning. Basically > it can increase compile time and possibly result in worse register > allocations but that's a very vague worry. > > Anyway, if you're worried abut it, I would suggested writing some test cases > that match what your usage and see if you can measure differences. There > could be pathologies here we're unaware of. I'll try to do so! There is a fair amount of code involved in these "catch anything" handlers, so that's a place I can probably improve (fast checks earlier, shunt as much logic as possible to child methods). - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
