Google hedging their bets with ART?
Read a post today talking about Google offering up a new alternative VM on the Nexus 5. Instead of Dalvik, there is also ART. Where Dalvik is basically a JIT compiler, ART is really, from the description not a VM at all. The article author called Dalvik JIT compilation and ART AOT (Ahead-of-time) compilation, and then referred to both as VM's. The problem is this... why would anyone use a VM with something compiled ahead of time? The JVM and Dalvik are both wastes of memory and CPU cycles that are simply implemented to make the WORA concept work.
So the real question is why? Why would Google create ART when it already has Dalvik? Sure, pre-compiled binaries can be more performant. But there are also downsides. Most notably, you already have a runtime and it works. But on top of that, if new features are added, apps need to be recompiled. This is actually, in addition to WORA, one of the huge benefits of JIT compiled code. Only the VM needs to be updated, and anything that runs on it can benefit from improvements.
Also, with the advance in mobile processors over the last 5 years, the overhead of JIT based VM's is now at a point on mobile where it is on desktop. Negligable. Maybe, if you have a super low end processor it might make a noticeable difference. But on a high end machine, the overhead, both in terms of RAM and CPU cycles shouldn't really be noticeable except in synthetic benchmarks.
My thoughts are that this is Google preparing for a potential loss to Oracle over their copying of mass parts of the Java API. See, the argument Oracle made was that Google was free to create their own VM that consumed Java code as long as the resultant files complied with certain Java compliance tests. By re-compiling the existing apps to a new format which doesn't consume Java or Java-like code and doesn't run on a Java-like VM this might allow Google a way around further infringement charges without forcing developers who write Android apps to learn a whole new language.
I'm not an IP lawyer, so I can't reliably guess whether or not this would get them out of the woods. But I can't think of an honest reason, especially with the current rate of progress in mobile chips to abandon Dalvik aside from legal reasons.
As a developer with a decent understanding of the concepts at hand, it seems an utter waste of time to not only produce a new run time, but to write code which re-compiles existing apps for that run time. Neither of those are trivial tasks. Both, individually are monstrously large tasks. And I simply don't see the payoff. In fact, as I've said already above, JIT compilation is actually very good, especially for an eco-system as fragmented and unstable as Android.
In fact, I would wager that for the same effort, Google could probably improve Dalvik severalfold on the performance and reliability front.
That is exactly what Microsoft does with .Net. And even with the multitude of frameworks Microsoft has built, the mass of compilers they have built, their absolutely massive wealth of talent on the topic, they have NEVER invested in code which re-compiled apps from one framework to run on another. And trust me, people have wanted it, and having it would have helped a ton. Especially with Windows 8.
This, I hope paints a picture of how much effort needs to go into such a move. And that should show you why no one would simply invest that effort out of the goodness of their hearts. If Oracle wins, Google needs a viable answer as soon as possible. Past damages could already be massive. And the court could order Google to bring Dalvik into compliance with Java or abandon it. I don't think, this far down the road, that Google can afford to make Dalvik Java compliant, which means they would need a replacement instead.
On the flip-side of this. This is a REALLY COOL project at Google. And, ironically, it was that which triggered this. Having worked in the programming industry for several years now, I can tell you one thing. If something is really cool, it is most likely something not commercially viable. I personally would love to see Microsoft do something similar between its platforms. I personally would love to be a part of either my fictitious Microsoft project or this real Google one. If the re-compiling part is done correctly, it could be used to adapt code to future runtimes. Which could, in the long run have a huge theoretical ROI with a much smaller investment.
So the real question is why? Why would Google create ART when it already has Dalvik? Sure, pre-compiled binaries can be more performant. But there are also downsides. Most notably, you already have a runtime and it works. But on top of that, if new features are added, apps need to be recompiled. This is actually, in addition to WORA, one of the huge benefits of JIT compiled code. Only the VM needs to be updated, and anything that runs on it can benefit from improvements.
Also, with the advance in mobile processors over the last 5 years, the overhead of JIT based VM's is now at a point on mobile where it is on desktop. Negligable. Maybe, if you have a super low end processor it might make a noticeable difference. But on a high end machine, the overhead, both in terms of RAM and CPU cycles shouldn't really be noticeable except in synthetic benchmarks.
My thoughts are that this is Google preparing for a potential loss to Oracle over their copying of mass parts of the Java API. See, the argument Oracle made was that Google was free to create their own VM that consumed Java code as long as the resultant files complied with certain Java compliance tests. By re-compiling the existing apps to a new format which doesn't consume Java or Java-like code and doesn't run on a Java-like VM this might allow Google a way around further infringement charges without forcing developers who write Android apps to learn a whole new language.
I'm not an IP lawyer, so I can't reliably guess whether or not this would get them out of the woods. But I can't think of an honest reason, especially with the current rate of progress in mobile chips to abandon Dalvik aside from legal reasons.
As a developer with a decent understanding of the concepts at hand, it seems an utter waste of time to not only produce a new run time, but to write code which re-compiles existing apps for that run time. Neither of those are trivial tasks. Both, individually are monstrously large tasks. And I simply don't see the payoff. In fact, as I've said already above, JIT compilation is actually very good, especially for an eco-system as fragmented and unstable as Android.
In fact, I would wager that for the same effort, Google could probably improve Dalvik severalfold on the performance and reliability front.
That is exactly what Microsoft does with .Net. And even with the multitude of frameworks Microsoft has built, the mass of compilers they have built, their absolutely massive wealth of talent on the topic, they have NEVER invested in code which re-compiled apps from one framework to run on another. And trust me, people have wanted it, and having it would have helped a ton. Especially with Windows 8.
This, I hope paints a picture of how much effort needs to go into such a move. And that should show you why no one would simply invest that effort out of the goodness of their hearts. If Oracle wins, Google needs a viable answer as soon as possible. Past damages could already be massive. And the court could order Google to bring Dalvik into compliance with Java or abandon it. I don't think, this far down the road, that Google can afford to make Dalvik Java compliant, which means they would need a replacement instead.
On the flip-side of this. This is a REALLY COOL project at Google. And, ironically, it was that which triggered this. Having worked in the programming industry for several years now, I can tell you one thing. If something is really cool, it is most likely something not commercially viable. I personally would love to see Microsoft do something similar between its platforms. I personally would love to be a part of either my fictitious Microsoft project or this real Google one. If the re-compiling part is done correctly, it could be used to adapt code to future runtimes. Which could, in the long run have a huge theoretical ROI with a much smaller investment.
Comments
Post a Comment