The justification that I’ve seen for shall we say “Bastardizing” the Java bytecodes in Android was performance. (I suspect there is another reason.) However by changing the byte codes haven’t they made hardware acceleration technologies such as Jazelle moot, and thus actually degraded the performance available for a Mobile Java platform?
It appears counter intuitive to me knowing that the target platform is a ARM based mobile platform. While it MIGHT give you better performance on other CPU architectures it seems to spit in the face of ARM and Jazelle.
What sort of quantitative effect does it have on Java performance?
Does it actually improve performance, and if so how?
What’s the effect on other platforms? (i.e. x86,mips,yadda,yadda,yadda…)
Yes Dalvik makes Jazelle useless. The only question is was Jazelle useful to begin with or is it 90% marketing hype? A good JIT or AOT(ahead of Time) compiler tends to give much better performance than trying to use specialized instructions. The register based approach of Dalvik might be faster than a traditional java bytecode interpreter but if the difference in minor between that of an interpreter and that of a JIT. Hopefully one of the next versions of Android has a JIT.
It takes ~5-10 years to write a good virtual machine with state of the art garbage collectors and optimizers. Sun (and Microsoft) have spent those years. Google hasn’t. Hopefully they will keep investing in it so that one day Android Java code isn’t a 90% slower than it should be.
Unlike most virtual machines and true Java VMs which are stack machines, the Dalvik VM is a register-based architecture.
Being optimized for low memory requirements, Dalvik has some specific characteristics that differentiate it from other standard VMs:
- The VM was slimmed down to use less space.
- Dalvik has no just-in-time compiler.
- The constant pool has been modified to use only 32-bit indexes to simplify the interpreter.
- It uses its own bytecode, not Java bytecode.
Moreover, Dalvik has been designed so that a device can run multiple instances of the VM efficiently.
Edit: See Wikipedia: Open Handset Alliance. The founding member includes Intel, Motorola, Qualcomm, and Texas Instruments. ARM joined an year later in December, 2008. So, I guess it didn’t make sense for these companies to rely on a proprietary technology by then non-member, when the goal was to create opensource iPhone/Blackberry competitor.
I was actually under the impression that Dalvik was intended more for space efficiency than execution efficiency. Also from Wikipedia:
An uncompressed .dex file is typically a few percent smaller in size than a compressed .jar (Java Archive) derived from the same .class files.
While the current phones may use an ARM with Jazelle support, that’s not necessarily true going forward.
Also from Wikipedia (warning: hearsay):
The published specifications are very incomplete, being only sufficient for writing operating system code that can support a JVM that uses Jazelle. The declared intent is that only the JVM software needs to (or is allowed to) depend on the hardware interface details. This tight binding facilitates that the hardware and JVM can evolve together without affecting other software. In effect, this gives ARM Holdings considerable control over which JVMs are able to exploit Jazelle. It also prevents open source JVMs from using Jazelle.
Once they add a JITter to Dalvik, it will all be a moot point.