Those of you who kept following IcedRobot might have seen that quite some work went into Daneel over the past months. He¹ is in charge of parsing Android applications containing code intended to run on a Dalvik VM and transforming this code into something which can run on any underlying Java VM. So he is a VM compatible with Dalvik on top of a Java VM, or at least that’s what he wants to become.

So Daneel is multilingual in a strange way, he can read and understand Dalvik bytecode, but he only speaks and writes Java bytecode. To understand how he can do that we have to look at the differences between those two dialects.

Registers vs. Stack: We know Dalvik bytecode uses a register-machine, and Java bytecode uses a stack-machine. But each method frame on that stack-machine not only has an operand stack, it also has an array of local variables. Unfortunately this distinction is lost in our register-machine. To understand what this means, let us look at a full Java-Dalvik-Daneel round-trip for a simple method like the following.

public static int addConst(int val) {
   return val + 123456;
}

The first stop on our round-trip is the Java bytecode. So after we push this snippet through javac we get the following code which makes use of both, an operand stack and local variables.

public static int addConst(int);
  [max_stack=2, max_locals=1, args_size=1]
   0: iload_0
   1: ldc #int 123456
   3: iadd
   4: ireturn

The second stop takes us to the Dalvik bytecode. We push the above code through the dx tool and are left with the following code. Note that the distinction between the operand stack and local variables is lost completely, everything is stored in registers.

public static int addConst(int);
  [regs=2, ins=1, outs=0]
   0: const v0, #0x1E240
   1: add-int/2addr v0, v1
   2: return v0

The third and last step is Daneel reading the Dalvik bytecode and trying to reproduce sane Java bytecode again. The following is what he spits out after chewing on the input for a bit.

public static int addConst(int);
  [max_stack=2, max_locals=2, args_size=1]
   0: ldc #int 123456
   1: istore_1
   2: iload_1
   3: iload_0
   4: iadd
   5: istore_1
   6: iload_1
   7: ireturn

The observant reader will notice the vast difference between what we had at the beginning of our round-trip and what we ended up with. Daneel maps each Dalvik register to a Java local variable. Fortunately any decent Java VM will optimize away the unnecessary load and store instructions and we can achieve acceptable performance with this naive approach already.

Untyped Instructions: Another big difference might not be that obvious at first glance. Notice how the instruction at label 0 in the above Dalvik bytecode (the second stop on our round-trip) accesses register v0 without specifying the exact type of that register? The only thing Daneel can determine at that point in the code is that it’s a 32-bit value we are dealing with, it could be an int or a float value. For zero-constants it could even be a null reference we are dealing with. The exact type of that register is not revealed before the instruction at label 1, where v0 is read again by a typed instruction. It’s at that point that we learn the exact type of that register.

So Daneel has to keep track of all register types while iterating through the instruction stream to determine the exact types and decide which Java bytecode instructions to emit. I intend to write a separate article about how this is done by Daneel in the following days, so stay tuned.

Disclaimer: This is a technical description of just two major differences between Dalvik bytecode and Java bytecode. All political discussions about differences or similarities between Dalvik and Java in general are outside the scope of this article and I won’t comment on them.

¹ Yes, Daneel is male. His girlfriend is called Ika. Together they love to drink iced tea because they try to get off caffeine. They even have a butler working for them who is called Jenkins, a very lazy guy who regularly was seen to crash during work.