6 ms·

> They wrote their own runtime -- which, to this day, is at a great performance disadvantage compared to OpenJDK This is completely incorrect. OpenJDK is abso

> They wrote their own runtime -- which, to this day, is at a great performance disadvantage compared to OpenJDK This is completely incorrect. OpenJDK is absolutely not optimized for mobile and it would have been a disaster on mobile. A lot of the Dalvik runtime and libraries have been rewritten with performance and memory in mind.

pron 11y ago
Some public benchmarks are old, but they were done after Dalvik had gotten its JIT (both runtimes have seen huge improvement since), and after it had been "optimized for mobile": https://blogs.oracle.com/javaseembedded/entry/how_does_android_22s_performance_stack_up_against_java_se_embedded https://blogs.oracle.com/javaseembedded/entry/how_does_andro... You are right that Dalvik was written to be optimized for mobile, but you have to understand compared to what. Dalvik is optimized for mobile compared to simple VMs that don't have a lot of work put into them -- not compared to HotSpot. Java's embedded versions have had a lot more effort put into them than Dalvik. Dalvik itself was plan B for Google, after they'd failed to secure a licensing deal with Sun (and didn't want OpenJDK's GPL). It wasn't anyone's first choice, and certainly wasn't some new powerful technology. Just a VM that was good enough compared to the effort that's been put into it. There are open source (obviously) OpenJDK distributions[1] specifically made for embedded devices (although you can build them yourself), and (proprietary) editions of Java have been running on devices as constrained as SIM cards for much longer than Android exists. [1]: http://www.azulsystems.com/products/zulu-embedded http://www.azulsystems.com/products/zulu-embedded
- zak_mc_kracken 11y ago
  You are glossing over the fact that Dalvik is a multiprocess VM. There is no such JVM, even today. This aspect and the Dalvik bytecode are the main reasons why Dalvik is so fast on mobile. No other VM (or JVM) can realistically compete, especially not HotSpot. Not now and certainly not back then.
  - pron 11y ago
    > You are glossing over the fact that Dalvik is a multiprocess VM. Making HotSpot multi-process would have been a much smaller effort for Google. It really isn't that hard. > No other VM (or JVM) can realistically compete, especially not HotSpot. Not now and certainly not back then. I've just shown you how HotSpot embedded handily beats Dalvik. Remember, Dalvik was Google's plan B. It wasn't anyone's first choice, and certainly not some cool groundbreaking technology. It's a not-too-shabby VM for the amount of effort put into it (which isn't much), and it was available for Google to buy. That's all.
    - cactusface 11y ago
      Why would you want a multi-process VM anyway?
    - sangnoir 11y ago
      Was the is the performance difference between HotSpot and Dalvik worth $45 million in 2006 dollars?[1] Those were the alleged licensing terms proposed by Sun ($20 million upfront + 10% Android revenue capped at $25 million). Your budget determines the kind of software you get. On a purely engineering basis, Hotspot might have been the better option, Business-wise, Dalvik made sense to Google. 1. http://www.pcworld.com/article/253666/a_timeline_of_oracles_java_lawsuit_against_google.html http://www.pcworld.com/article/253666/a_timeline_of_oracles_...
      - pron 11y ago
        I don't know, but it was certainly worth much more than the $0 they would have paid for HotSpot if they'd had the guts to go with the GPL. That's what's missing from the timeline: * March 2007 -- Sun open sources the JDK at the perfect moment for Google to adopt it. Google chooses not to because they don't like the GPL. I think the phone vendors would have caved. It might have taken another year, but they would have realized they had no choice once the app store opened in July 2008, as none of them could have had the brand recognition to build an attractive software platform to rival the iPhone.

pron 11y ago

Some public benchmarks are old, but they were done after Dalvik had gotten its JIT (both runtimes have seen huge improvement since), and after it had been "optimized for mobile": https://blogs.oracle.com/javaseembedded/entry/how_does_android_22s_performance_stack_up_against_java_se_embedded https://blogs.oracle.com/javaseembedded/entry/how_does_andro... You are right that Dalvik was written to be optimized for mobile, but you have to understand compared to what. Dalvik is optimized for mobile compared to simple VMs that don't have a lot of work put into them -- not compared to HotSpot. Java's embedded versions have had a lot more effort put into them than Dalvik. Dalvik itself was plan B for Google, after they'd failed to secure a licensing deal with Sun (and didn't want OpenJDK's GPL). It wasn't anyone's first choice, and certainly wasn't some new powerful technology. Just a VM that was good enough compared to the effort that's been put into it. There are open source (obviously) OpenJDK distributions[1] specifically made for embedded devices (although you can build them yourself), and (proprietary) editions of Java have been running on devices as constrained as SIM cards for much longer than Android exists. [1]: http://www.azulsystems.com/products/zulu-embedded http://www.azulsystems.com/products/zulu-embedded

zak_mc_kracken 11y ago
You are glossing over the fact that Dalvik is a multiprocess VM. There is no such JVM, even today. This aspect and the Dalvik bytecode are the main reasons why Dalvik is so fast on mobile. No other VM (or JVM) can realistically compete, especially not HotSpot. Not now and certainly not back then.
- pron 11y ago
  > You are glossing over the fact that Dalvik is a multiprocess VM. Making HotSpot multi-process would have been a much smaller effort for Google. It really isn't that hard. > No other VM (or JVM) can realistically compete, especially not HotSpot. Not now and certainly not back then. I've just shown you how HotSpot embedded handily beats Dalvik. Remember, Dalvik was Google's plan B. It wasn't anyone's first choice, and certainly not some cool groundbreaking technology. It's a not-too-shabby VM for the amount of effort put into it (which isn't much), and it was available for Google to buy. That's all.
  - cactusface 11y ago
    Why would you want a multi-process VM anyway?
  - sangnoir 11y ago
    Was the is the performance difference between HotSpot and Dalvik worth $45 million in 2006 dollars?[1] Those were the alleged licensing terms proposed by Sun ($20 million upfront + 10% Android revenue capped at $25 million). Your budget determines the kind of software you get. On a purely engineering basis, Hotspot might have been the better option, Business-wise, Dalvik made sense to Google. 1. http://www.pcworld.com/article/253666/a_timeline_of_oracles_java_lawsuit_against_google.html http://www.pcworld.com/article/253666/a_timeline_of_oracles_...
    - pron 11y ago
      I don't know, but it was certainly worth much more than the $0 they would have paid for HotSpot if they'd had the guts to go with the GPL. That's what's missing from the timeline: * March 2007 -- Sun open sources the JDK at the perfect moment for Google to adopt it. Google chooses not to because they don't like the GPL. I think the phone vendors would have caved. It might have taken another year, but they would have realized they had no choice once the app store opened in July 2008, as none of them could have had the brand recognition to build an attractive software platform to rival the iPhone.