views:

3558

answers:

4

Hi All,

I am currently writing a paper on the Android platform. After some research, it's clear that Dalvik has room for improvement. I was wondering, what do you think would be the best use of a developer's time with this goal?

JIT compilation seems like the big one, but then i've also heard this would be of limited use on such a low resource machine. Does anyone have a resource or data that backs this up?

Are there any other options that should be considered? Aside from developing a robust native development kit to bypass the VM.

For those who are interested, there is a lecture that has been recorded and put online regarding the Dalvik VM.

Any thoughts welcome, as this question appears subjective i'll clarify that the answer I'll accept must have some justification for proposed changes. Any data to back it up, such as the improvement in the Sun JVM when it was introduced, would be a massive plus.

Kind regards,

Gavin

A: 

One of the main problems with Dalvik is performance, which is terrible I heard, but one of the things I would like most is the addition of more languages.

The JVM has had community projects getting Python and Ruby running on the platform, and even special languages such as Scala, Groovy and Closure developed for it. It would be nice to see these (and/or others) on the Dalvik platform as well. Sun has been working on the Da Vinci machine as well, a dynamic typing extension of the JVM, which indicates a major shift away from the "one language fits all" philosophy Sun has followed over the last 15 years.

wvdschel
Android now has support for scripting language. It's not much, but will improve : http://stackoverflow.com/questions/101754/is-there-any-way-to-run-python-on-android.
e-satis
A: 

<rant>

I'd like to see Dalvik replaced with a standard JVM... I know there are a bunch a licensing issues, but Dalvik is nothing more than a direct mapping from one byte-code to another - despite Google's claims of 'optimisation' and all that jazz.

It feels like incompatibility for incompatibility sake.

http://www.itworld.com/071116googlesun

http://www.betaversion.org/~stefano/linotype/news/110/

http://www.oreillynet.com/onjava/blog/2007/11/dalvik_googles_tweaked_nonstan.html

</rant>

Cogsy
And your proof of this assertion is...what, exactly?
CommonsWare
ppht, there's no proving things on the internet! But here are some links for you to read. In my 'personal' opinion, there was no real technical reason for Google to create Dalvik.
Cogsy
The JVM is a stack based, Dalvik a register based VM. There is *a lot more* different than just mapping one opcode to a different one (for incompatibilitys sake).That said: Of course there were no *technical* reasons not to use a JVM, but Google wanted to give Android away for free -- and therefore it would have been a bad idea having to pay Sun a licensing fee for every (JVM-equipped) mobile phone produced with that OS.
Henning
+5  A: 
  1. Better garbage collection: compacting at minimum (to eliminate memory fragmentation problems experienced today), ideally less CPU intensive at doing the collection itself (to reduce the "my game frame rates suck" complaints)
  2. JIT, as you cite
  3. Enough documentation that, when coupled with an NDK, somebody sufficiently crazy could compile Dalvik bytecode to native code for an AOT compilation option
  4. Make it separable from Android itself, such that other projects might experiment with it and community contributions might arrive in greater quantity and at a faster clip

I'm sure I could come up other ideas if you need them.

CommonsWare
+2  A: 
  1. JIT. The stuff about it not helping is a load of crap. You might be more selective about what code you JIT but having 1/10th the performance of native code is always going to be limiting

  2. Decent GC. Modern generational garbage collectors do not have big stutters.

  3. Better code analysis. There are lot of cases where allocations/frees don't need to be made, locks held, and so on. It allows you to write clean code rather than doing optimizations that the machine is better at

In theory most of the higher level languages (Java, Javascript, python,...) should be within 20% of native code performance for most cases. But it requires the platform vendor to spend 100s+ developer man years. Sun Java is getting good. They have also been working on it for 10 years.

hacken
Your last point highlights the fundamental design flaw of choosing to write Dalvik instead of starting with a established code base. If they chose Mono, they'd be years ahead of where they are now as a platform.
280Z28
280Z28, that's a joke right?
soc