The Android avalanche today at IO included an announcement that Android L will use a new default runtime called ART. This is really a pretty big deal, that is if you’re an application-runtime geek.
Since Android’s launch in 2008, the app runtime has been Dalvik, which is a story that never got the attention it deserved. It’s a novel register-based VM, not like Java’s at all, but whose bytecodes could be generated from Java’s with reasonable efficiency. A fully garbage-collected and (starting in 2011 or so) JITted VM, pretty power-efficient, and pretty fast. But never quite as power-efficient or fast as iOS apps, compiled from ObjC to ARM-native code; perhaps no classic VM ever could be.
So a native-code runtime was in order; and it’s a tribute to Dalvik and the people who built it that it took Google this long to make one that’s actually better.
Dalvik’ chief author is Dan Bornstein who, obviously, is an ace engineer; and also a nice guy. I saw his departure from Google as a significant management failure, and it troubled me. Anyhow, Dalvik is now a historical artifact, but I still see it as a remarkable piece of software, in production on a billion or so devices, that changed the world in nontrivial ways. Anyone who has their fingerprints on it should feel proud.
ART? A lot of runtimes have been built over the years, and this one reflects many of the important lessons learned. I’m sure that in certain benchmarks certain code sequences run twice as fast or even better. That doesn’t mean that your phone will feel twice as fast, but I expect that many things will feel faster and drain your battery slower; which is good.
Contributions
Comment feed for ongoing:
From: Osvaldo Doederlein (Jun 25 2014, at 17:12)
Dalvik was indeed a great piece of technology, but IMO for slightly different reasons; your post seems to imply that Dalvik was a great-performing mobile JVM, but this was only ever true with some qualification such as "for an interpreted JVM". Dalvik's greatest merits were (a) fixing some ancient screwups of Java, such as its very outdated binary format (dex is approximately a trillion times better than standard jar/class files), and the bytecode that you mention. Add to that other innovations like its process management (zygote system) and it was a much better system that traditional JVMs. IIRC, CLDC HotSpot actually had some of these optimizations, like some internal process sharing capability based on the never-really-finished JSR-121; but Sun's unwillingness to fix old sins limited what they could improve.
Still, last time I checked, Dalvik never had a first-class JIT; CLDC HotSpot was better. We certainly didn't make the investment that we could have done on Dalvik's JIT, maybe because the team didn't believe in the promised land of increasingly complex JIT compilers. Even with high-performance APIs for things like 3D graphics, current versions of Android wouldn't be competitive with iOS without the NDK, which allows a native code fallback whenever things get tough.
The performance of "application-level code" written in Java was not incredibly critical in a time when most heavy lifting was done by libraries/APIs/system services/game engines, so the app code is relatively small and mostly a driver or glue code for those libraries (which can use native code as needed). But now the mobile platforms are exploding, application code becoming orders of magnitude bigger and more complex, then even the best JIT won't be good enough.
[link]
From: Markus Köhler (Jun 26 2014, at 09:07)
I agree with Oswaldo, dalviks sharing capabilties are a very remarkable achievement. I know at least one attempt of a big company to implement something similiar ans it failed.
[link]