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-to26663553.html > > 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.
