Well, we could see what is actually happening, of course...prepare reduced bytcode versions of both and see what assembly code results after optimization. I've got $5 that there's a type check.
On Saturday, December 12, 2009, Daniel Hicks <[email protected]> wrote: > 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. > > > -- 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.
