[scala] Um, what the hell? (Scala puzzlers 2: Horrific evil performance issues with Application trait)

[David MacIver]

http://blogs.sun.com/navi/entry/scala_puzzlers_part_2

Anyone know what's going on here? I've tried to adopt a policy of not
using Application anyway (as it has other significant problems), but
it would be really good to know what's causing this. The performance
difference is dramatic - it looks like about two orders of magnitude
on my machine! I'm pretty horrified.

This isn't necessarily scala's fault of course - it's just as likely
the JIT doing something daft, but unfortunately it's the scala
compiler's responsibility to adapt to the quirks of the JIT, not the
other way round.

[Ismael Juma]

Hi,

David MacIver <david.maciver <at> gmail.com> writes:
> http://blogs.sun.com/navi/entry/scala_puzzlers_part_2
>
> Anyone know what's going on here?

I added a comment to the blog, but it's under moderation so repeating it here:

If you add -XX:+PrintCompilation to your launcher, you will notice that no
methods are compiled by the HotSpot JIT for the broken version. This means that
it runs purely in the interpreter and as such it's horribly slow. The fixed
version does not have the same issue.

My theory is that code that runs in the class initialiser cannot be JITed or
something similar and that is the source of the problem.

Regards,
Ismael

[Christos KK Loverdos]

Hi all,

The first thing that came to my mind after David's email is that -server and -client have different default values for the -XX:CompileThreshold option and that could be the source of the problem.

Ismael has verified that no compilation takes place....

On 7/24/08, Ismael Juma <mlists@...> wrote:

Hi,


David MacIver <david.maciver <at> gmail.com> writes:
> http://blogs.sun.com/navi/entry/scala_puzzlers_part_2
>
> Anyone know what's going on here?


I added a comment to the blog, but it's under moderation so repeating it here:

If you add -XX:+PrintCompilation to your launcher, you will notice that no
methods are compiled by the HotSpot JIT for the broken version. This means that
it runs purely in the interpreter and as such it's horribly slow. The fixed
version does not have the same issue.

My theory is that code that runs in the class initialiser cannot be JITed or
something similar and that is the source of the problem.

Regards,

Ismael

--
  __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com