Why is the stack-based JVM and Dalvik VM case-sensitive?

Question

I'm curious why Sun decided to make a stack-based JVM and Google decided to make a case-based DalvikVM?

I believe that the JVM cannot assume that a certain number of registers are available on the target platform, since it must be platform independent. Therefore, it simply postpones the allocation of registers, etc. To the JIT compiler. (Correct me if I am wrong.)

So the Android guys thought, “Hey, this is inefficient, let go of vm-based registration right away ...”? But wait, there are several different Android devices, how many registers did the Dalvik target do? Are Dalvik codecs hardcoded for a certain number of registers?

Do all current Android devices on the market have approximately the same number of registers? Or, is there a registry redistribution performed during dex boot? How does it all fit together?

Answer 1

There are several stack-based virtual machine attributes that fit well with Java development goals:

• The stack-based design makes very few assumptions about the target hardware (registers, CPU functions), so it is easy to implement a virtual machine on a wide range of hardware.

• Since operands for instructions are mostly implicit, the object code will be smaller. This is important if you are about to download code through a slow network connection.

Transitioning with a register-based scheme probably means that the Dalvik code generator does not have to work so hard to create execution code. Running on a very case-sensitive or poorly-registered architecture is likely to be discouraged by Dalvik, but this is not a common goal. ARM is a very average architecture.

---

I also forgot that the original version of Dalvik did not include JIT at all. If you intend to interpret instructions directly, then a case-based scheme is likely to be a winner for interpretation performance.

Answer 2

I can’t find the link, but I think Sun decided to use the stack-based bytecode method, since it makes it easier to run the JVM in a multi-register architecture (like IA32).

At Dalvik VM Internals by Google I / O 2008, creator of Dalvik Dan Bornstein , the following arguments are presented for choosing a register-based VM on a slide of 35 presentation slides :

Register a car

Why?

• avoid sending a command
• Avoid unnecessary memory access.
• use instruction flow efficiently (higher semantic density for each instruction)

and on slide 36:

Register a car

Statistics

• 30% less instructions
• 35% less code units
• 35% more bytes in the instruction stream
  • but we can consume two times at a time

According to Bornstein, this is "a common expectation of what you might find when converting a set of class files to dex files."

Relevant Part of Presentation Video

Answer 3

I do not know why Sun decided to found the JVM stack. Erlangs virtual machine, BEAM is registered for performance reasons. And Dalvik also seems to register for performance reasons.

From Pro Android 2 :

Dalvik uses registers as primarily storage units instead of stacks. As a result, Google hopes to follow up to 30% fewer instructions.

And regarding the code size:

Dalvik VM takes the generated Java class files and combines them into one or more Dalvik Executables (.dex) files. It reuses duplicate information from several class files, effectively reducing the space requirement (without compression) by half from the traditional .jar file. For example, the .dex file of a web browser application in Android is about 200 thousand, while the equivalent uncompressed version of .jar is about 500 thousand. The .dex file of the alarm clock is about 50 thousand. And it is approximately twice its size .jar.

And as I recall Computer architecture: the quantitative approach also concludes that the registration machine works better than the stack-based machine.