Question

I’m curious, why did Sun decide to make the JVM stack-based and Google decide to make the DalvikVM register-based?

I suppose the JVM can’t really assume that a certain number of registers are available on the target platform, since it is supposed to be platform independent. Therefor it just postpones the register-allocation etc, to the JIT compiler. (Correct me if I’m wrong.)

So the Android guys thought, “hey, that’s inefficient, let’s go for a register based vm right away…”? But wait, there are multiple different android devices, what number of registers did the Dalvik target? Are the Dalvik opcodes hardcoded for a certain number of registers?

Do all current Android devices on the market have about the same number of registers? Or, is there a register re-allocation performed during dex-loading? How does all this fit together?

Answer 1

There are a few attributes of a stack-based VM that fit in well with Java’s design goals:

1. A stack-based design makes very few
   assumptions about the target
   hardware (registers, CPU features),
   so it’s easy to implement a VM on a
   wide variety of hardware.

2. Since the operands for instructions
   are largely implicit, the object
   code will tend to be smaller. This
   is important if you’re going to be
   downloading the code over a slow
   network link.

Going with a register-based scheme probably means that Dalvik’s code generator doesn’t have to work as hard to produce performant code. Running on an extremely register-rich or register-poor architecture would probably handicap Dalvik, but that’s not the usual target – ARM is a very middle-of-the-road architecture.

---

I had also forgotten that the initial version of Dalvik didn’t include a JIT at all. If you’re going to interpret the instructions directly, then a register-based scheme is probably a winner for interpretation performance.