This Dalvik presentation (video) contains a seminar about the internals of the new Virtual Machine from Google. The Dalvik Virtual Machine (DVM) (Dalvik is a city up north in one of the fiords in Iceland) is the application workhorse behind the new Google’s Android platform. User applications can be written in Java (or any language that is compiled down to JVM .class files), and they can be executed on DVM. There is a number of unique architectural decisions that define the DVM.
There is no JIT. The rationale is that JIT on high application level does not provide that much benefits, given that all performance critical components and system libraries are already implemented natively anyway. There is JNI interface therefore application developers, if required, can provide critical components implemented natively too.
The .class format is not used directly. Instead, DVM is using DEX (Dalvik EXecutable) bytecode. It converts multiple .class files into a single DEX file. Also Dalvik does not use Java single-byte bytecodes. It has a new set of bytecodes, and uses register-based (instead of stack-based) virtual machine model. It uses stack for top-level method calls, but within a single method all execution frames are kept in registers.
DVM keeps garbage collector bit marking in a separate datastructure (not associated with objects themselves).
And, the interpreter uses few smart optimisation techniques to keep it all efficient. They managed to get down to a single read operation on a single bytecode dispatch in the interpreter – through aligning all the opcodes in 16-byte long memory units (cache lines).
Overall, Dalvik was designed with embedded applications in mind, with quite limited resources and short battery life. It leverages the existing Java (and JVM in general) applications, although it is not strictly Java platform itself. At the end of last year Dalvik generated some discussions when the SDK was released.