Re: [scala] r19952: performance degradation

[Johannes Rudolph]

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?

Thanks,
Johannes

On Sun, Dec 6, 2009 at 9:51 PM, Lukas Rytz <lukas...@epfl.ch> wrote:
> amazing.. this probably means that we can speed up any exception
> handler catching `Throwable`.
>
> On Sun, Dec 6, 2009 at 19:14, Paul Phillips <pa...@improving.org> wrote:
>>
>> On Sun, Dec 06, 2009 at 05:36:20PM +0100, Lukas Rytz wrote:
>> > Thanks for trimming it down. I'll have a look.
>>
>> Also, I reproduced the slowdown and verified that this diff alone is
>> enough to induce it.
>>
>> -          (NoSymbol, expectedType, exhCtx => {
>> +          (ThrowableClass, expectedType, exhCtx => {
>>
>> --
>> Paul Phillips      | Where there's smoke, there's mirrors!
>> Future Perfect     |
>> Empiricist         |
>> pal, i pill push   |----------* http://www.improving.org/paulp/
>> *----------
>
>

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[Daniel Hicks]

Performance win when? During normal execution or on the throw?

On Dec 7, 2:39 am, Johannes Rudolph <johannes.rudo...@googlemail.com>
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?
>
> Thanks,
> Johannes
>
>
>
> On Sun, Dec 6, 2009 at 9:51 PM, Lukas Rytz <lukas.r...@epfl.ch> wrote:
> > amazing.. this probably means that we can speed up any exception
> > handler catching `Throwable`.
>
> > On Sun, Dec 6, 2009 at 19:14, Paul Phillips <pa...@improving.org> wrote:
>
> >> On Sun, Dec 06, 2009 at 05:36:20PM +0100, Lukas Rytz wrote:
> >> > Thanks for trimming it down. I'll have a look.
>
> >> Also, I reproduced the slowdown and verified that this diff alone is
> >> enough to induce it.
>
> >> -          (NoSymbol, expectedType, exhCtx => {
> >> +          (ThrowableClass, expectedType, exhCtx => {
>
> >> --
> >> Paul Phillips      | Where there's smoke, there's mirrors!
> >> Future Perfect     |
> >> Empiricist         |

> >> pal, i pill push   |----------*http://www.improving.org/paulp/

[Marcelo Fukushima]

the sample was for a normal execution

> --
>
> You received this message because you are subscribed to the Google Groups "JVM Languages" group.
> To post to this group, send email to jvm-la...@googlegroups.com.
> To unsubscribe from this group, send email to jvm-language...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
>
>
>



--
http://mapsdev.blogspot.com/
Marcelo Takeshi Fukushima

[Charles Oliver Nutter]

On Mon, Dec 7, 2009 at 2:39 AM, Johannes Rudolph
<johannes...@googlemail.com> 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

[Daniel Hicks]

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 <head...@headius.com> wrote:
> On Mon, Dec 7, 2009 at 2:39 AM, Johannes Rudolph
>

> <johannes.rudo...@googlemail.com> 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...

[Charles Oliver Nutter]

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.

[Daniel Hicks]

Certainly there's a type check in the handler, but it should only
"cost" if an exception is handled.

There's also, of course, the cost of resolving the exception class
constant, but that's either done at class load time or in a "lazy"
fashion on first reference, and in either case shouldn't affect the
performance of repetitive operations.

On Dec 12, 7:59 pm, Charles Oliver Nutter <head...@headius.com> wrote:
> 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.
>