Performance improvements are really important given the rise of poor JVMs like Dalvik, though. Scala is really painful on Dalvik due to the amount of garbage it generates.
I wouldn't call Dalvik a poor JVM, just a JVM optimized for a certain mobile application mix (not so GC intensive) that Scala doesn't really support yet.
To get decent GC performance, you need a large space for copying, which doesn't work so well on mobile, so they probably went with a less efficient in-place collector. Its a trade off really: low memory operation or high performance even when a lot of garbage is generated (and memory isn't so expensive)?
WinRT has built in support for reference counting now (both in run-time and in its libraries); that's a big deal for mobile! Sure, the collector is still present and you can use it in C#, but...the game is changing quickly. Apple, of course, supports reference counting already, Dalvik does not as there is no easy way to bolt that onto Java (though I wouldn't be surprised if Google eventually does what MSFT did with WinRT).
Disclosure: MSFT employee and general programming languages hacker.
This comparison makes no sense, the two JVM's were designed with fundamentally different goals.
At any rate, if you really wanted to compare, you would have to run the benchmarks on the same platform, i.e. Dalvik on the desktop or HotSpot on Android.
This comparison makes no sense, the two JVM's were designed with fundamentally different goals.
What they are designed for and what they are quite commonly used for are different things. Both are used for running my application code. Serious performance problems on one makes that worse, regardless of whether it is worse-as-designed or not.
No, it's a JVM optimized for "not being something Oracle can demand money for."
It's an okay JVM at best, and it's a pain in the ass to deal with because of its lack of support for things that are at this point basic on the JVM, i.e. code generation. And it's not just the different-to-be-different bytecode environment that does that, but bad design decisions like a laughably low class limit--which, in addition to making Groovy, Rhino, etc. unusable, hobbles Scala, too, and will hobble Java 8 when that comes out.
We're talking technical here and you're throwing in a legal argument?!? What does this have to do with the implementation of the JVM?
"Be different enough to not get sued" is a technical requirement as well as a legal one because it informs the design of your product. For example: the use of a different bytecode format in Dalvik pretty obviously had much more to do with "we can't make it look like a real JVM because we'll get sued" than efficiency; it's not a significantly better format than the standard Java bytecode system and using it trashes your compatibility with common Java libraries and tools.
Obviously, you are an expert on virtual machines and the Android team should listen to your wisdom.
Good ad hominem, bro. How's that working out for you?
I am not an expert, no, but I do know a few things about them and I know a few more about application development, on Android and off. Dalvik is not a good citizen of the Java ecosystem (as evidenced by its inability to do things that are considered very normal, i.e. Groovy or Rhino for scripting). You can't do really basic stuff like LiveConnect because of the twin fails of no bytecode generation (there's no dexer on-device) and, as mentioned, the class limit does a number on Scala and will hose Java 8. These are technical problems that stem from decisions made during the design process, and they're not edge case problems--well, the Scala bit is, but you can surface the same problem by just having a lot of dependencies that pull in a lot of class files.
When you're talking JVMs, you must compare to HotSpot because that's the main game in town. Dalvik doesn't compare well the design decisions inside of Dalvik serve to hobble developers who are not looking to write very simple, Android-idiomatic (which is not Java-idiomatic) CRUD apps. And that sucks. I would like it to be better. It isn't at present. I don't hold out a lot of hopes for improvement, though I would like to be wrong.
True, although it's not entirely clear from this Scala-on-JVM benchmark whether there'd be a comparable speedup for Scala-on-Dalvik. Depends on the reasons for the speedup I assume.
