But I don't know why performance in "normal execution" would be affected. I've never seen any difference in code generation, either at the bytecode level or at the (non Sun) JIT level, based on what exception is being caught. There can, of course, be a lot of difference based on how exception ranges are nested, etc.
On Dec 10, 8:32 am, Charles Oliver Nutter <[email protected]> wrote: > On Mon, Dec 7, 2009 at 2:39 AM, Johannes Rudolph > > <[email protected]> wrote: > > Cross-posting to the JVM Languages group. You might want to see the > > history of this thread as well: > > >http://old.nabble.com/-scala--r19952%3A-performance-degradation-to266... > > > Can anyone from the experts comment on the fact why using null as > > exception type ('any' in javap) in a handler instead of Throwable > > results in such a big performance win (> 2x) ? Is it a special > > performance optimization in the Hotspot VM for finally clauses? Is it > > known and documented somewhere? > > My very rough guess would be that catching throwable requires the > exception-handling mechanism to still do a typecheck to ensure what it > has caught is a Throwable, even though in theory all thrown objects > should extend Throwable. Semantically the two end up being the same, > since you know and I know that all thrown objects extend Throwable, > but catching null probably allows the VM to explicitly eliminate that > check. > > In working on JRuby we've run into similar situations, where Hotspot > has been well-tuned to run the exact code that javac emits, and > diverging from that code often produces unexpected results. In our > case, we've actually managed to crash the JVM by emitting perfectly > normal bytecode that didn't match the way javac would compile the same > logic. This performance difference is surprising in general, but not > surprising to me in specific, given what I've seen in my bytecode > generation adventures. > > - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
