3 ms·

The point of using a VM was to abstract away from specific processor targets, since embedded processors run from ARM to PowerPC, MIPS, x86, and others (and mult

The point of using a VM was to abstract away from specific processor targets, since embedded processors run from ARM to PowerPC, MIPS, x86, and others (and multiple variants of each processor, support additional instruction sets). This allows OEMs to produce an x86 port of stuff while keeping 95% of all apps which don't need native compilation.

nimrody 17y ago
Well, you could always ship software in platform neutral code and make the final transition to native code when they are installed (either with something like gcj or use some intermediate representation like LLVM does).
- wgren 17y ago
  That is basically what JIT is. Why reinvent the wheel when they can use the resources that has been poured into JVM research?
  - jbellis 17y ago
    Except they can't, really. Dalvik is completely unrelated to Hotspot or any other JVM out there. (Remember that Android doesn't run Java class files natively, it's first compiled into dex.)
    - wgren 17y ago
      Right you are jbellis. Had forgotten that Dalvik isn't just a small JVM but a completely different architecture (register based, etc). But anyway, what nimrody suggested is what they are doing - using platform neutral Dalvik bytecode and then transition to native through JIT.
- theBobMcCormick 17y ago
  I think that would have it's own complexities. You'd have to ship each phone with a compiler and related toolchain. You'd also end up with two copies of each application installed on the users phone (one in the neutral format and one native). Sound like kind of a messy approach. Really, the existing non-jit'ed Dalvik VM runs fast enough. If you think about it, their decision to ship a non-JIT VM and enhance the platform with JIT later is very much like Apple's approach with the iPhone of initially shipping the product without cut-and-paste and without any native API for third party apps, but then enhancing the platform later by adding those (and many other) features later. Both companies shipped when they had a platform that was "good enough", then have kept iterating and improving.

nimrody 17y ago

Well, you could always ship software in platform neutral code and make the final transition to native code when they are installed (either with something like gcj or use some intermediate representation like LLVM does).

wgren 17y ago
That is basically what JIT is. Why reinvent the wheel when they can use the resources that has been poured into JVM research?
- jbellis 17y ago
  Except they can't, really. Dalvik is completely unrelated to Hotspot or any other JVM out there. (Remember that Android doesn't run Java class files natively, it's first compiled into dex.)
  - wgren 17y ago
    Right you are jbellis. Had forgotten that Dalvik isn't just a small JVM but a completely different architecture (register based, etc). But anyway, what nimrody suggested is what they are doing - using platform neutral Dalvik bytecode and then transition to native through JIT.
theBobMcCormick 17y ago
I think that would have it's own complexities. You'd have to ship each phone with a compiler and related toolchain. You'd also end up with two copies of each application installed on the users phone (one in the neutral format and one native). Sound like kind of a messy approach. Really, the existing non-jit'ed Dalvik VM runs fast enough. If you think about it, their decision to ship a non-JIT VM and enhance the platform with JIT later is very much like Apple's approach with the iPhone of initially shipping the product without cut-and-paste and without any native API for third party apps, but then enhancing the platform later by adding those (and many other) features later. Both companies shipped when they had a platform that was "good enough", then have kept iterating and improving.