64-Bit Support

ART was designed in mind with modularity of the various target architectures in which it is supposed to run on. As such, it provides a multitude of compiler-backends targeting today’s most common architectures such as ARM, x86 and MIPS. In addition, 64-bit support for ARM64, x86-64 and while still not implemented, also MIPS64.

While we have gone more in depth of the advantages and implications of switching over to 64-bit architectures in the iPhone 5s review, the main points to take away are the availability of an increased address space, generally increased performance, and vastly increased cryptographic capabilities and performance, all while maintaining full 32-bit compatibility with all existing apps.

An important difference that Google is applying over Apple, at least inside VM runtime applications, is that they are using reference compression to avoid the usual memory bloat that comes with the switch to 64-bit. The VM retains simple 32-bit references.

Google has made available some preview benchmarks showcasing the performance gains both on x86 and ARM platforms. The x86 benchmarks were executed on a Intel BayTrail system, and show a 2x to 4.5x speedup in various RenderScript benchmarks. On the ARM side, the crypto performance gains over 32-bit were showcased on an A57/A53 system. Both of these are relatively non-representative of one should really expect in real-world use-cases so they’re not that useful as a performance prediction.

However Google also made some interesting numbers available on one of their internal build-systems called Panorama. Here we can see a 13 to 19% increase in performance by simply switching over the ABI. It is also good to see how ARM’s Cortex A53 is able to make a bigger impact on performance when in AArch64 mode than the A57 cores.

Google claims that 85% of all current Play Store apps are immediately ready to switch over to 64 bit - which would mean that only 15% of applications have some kind of native code that needs targeted recompiling by the developer to make use of 64-bit architectures. This is a great win for Google and I expect the shift over to 64-bit to be very fast once silicon vendors start shipping 64-bit SoCs in the coming year.


In many points, Google has delivered its “Performance boosting thing” and addressed much of the shortcomings that have plagued Android for years.

ART patches up many of the Achilles’ heels that comes with running non-native applications and having an automatic memory management system. As a developer, I couldn’t have asked for more, and most performance issues that I needed to work around with clever programming no longer pose such a drastic problem anymore.

This also means that Android is finally able to compete with iOS in terms of application fluidity and performance, a big win for the consumer.

Google still promises to evolve ART in the future and its current state is definitely not what it was 6 months ago, and definitely not what it will be once the L release is made available in its final form in devices. The future looks bright and I can’t wait to see what Google will do with its new runtime.

Garbage Collection: Theory and Practice


View All Comments

  • hahmed330 - Wednesday, July 2, 2014 - link

    One Stone... Three birds... Reply
  • Notmyusualid - Wednesday, July 2, 2014 - link

    Just switched my GS5 over to Art, from Dalvik, and Antutu result dropped by 8%...

    Yes, the choice is on the stock ROM, just goto developer options, and select runtime.
  • tuxRoller - Thursday, July 3, 2014 - link

    Use ANY other benchmark. Who the hell knows how antutu works?
    For micro benchmarks try geekbench.
    If you're willing to do some compiling, linaro has a bunch of benchmarks it uses to determine progress.
  • Notmyusualid - Thursday, July 3, 2014 - link

    Call me crazy, but I don't pay for apps....

    I take only the free ones.

    I see no free Geekbench on the Play Store.
  • tuxRoller - Friday, July 4, 2014 - link

    I didn't realize you had to pay for it.
    Regardless, antutu is junk. Why? Because we don't know exactly what it does, or how it does it.
    The other option I mentioned is pick some of the linaro benchmark tools and compile them.
    I won't call you crazy for not buying apps because I don't know your situation. What I do, however, is try free versions and if they are good I buy them. They don't cost much and I don't waste battery with ads I'll ignore.
  • Krysto - Thursday, July 3, 2014 - link

    I thought it was clear that the ART in L is NOT the one in KitKat, and has been revamped quite a bit. The final one, 5 months from now, will probably have big changes, too. Reply
  • Notmyusualid - Thursday, July 3, 2014 - link

    Will keep an eye out for it, but I'm expecting this to be no big deal now. Reply
  • ergo98 - Wednesday, July 2, 2014 - link

    Too much has been made regarding AOT and JIT. Note that Dalvik generally only JITs the DEX once, storing the result in /data/dalvik-cache.

    The big difference between Dalvik and ART is simply that ART was rewritten from the ground up based upon everything they learned from the Dalvik experience.
  • errorr - Thursday, July 3, 2014 - link

    That and because of the Oracle lawsuit over Dalvik which is nicely mooted by ART. Reply
  • doubledeej - Wednesday, July 2, 2014 - link

    It never ceases to amaze me how many problems that were solved decades ago in computing are problems on modern computing platforms.

    Real compilation of code has been around forever -- the norm, in fact, for desktop and server computing with a few notable exceptions. Yet somehow taking what effectively amounts to interpreting code (just-in-time compilation is very similar to interpretation) and switching to compiling it ahead of execution is being touted as a new idea.

    The fact that Android has pretty much been completely reliant upon JIT running in a VM has always made me scratch my head. As clearly spelled out in the article, it cause huge performance issues, along with significant hits to battery life. And we're talking about mobile devices where we've got relatively low-power CPUs and GPUs, little memory, and finite battery capacity. But it has been the way that Android has worked from the beginning. Crazy that it hasn't really been addressed until now.

    And the idea that operating systems and development languages be in charge of garbage collection, and people being surprised that it causes performance hits, seems odd to me too. Managing your own memory isn't that hard to do. And it is a hell lot more efficient doing it yourself than making the language or OS figure out how to do it. It's a "clean up your own mess and put things back where you want them" vs. "make someone else do it and let them try to figure out where things go" situation. It might make development easier for entry-level developers, but it certainly isn't an efficient way to do things when performance and user experience are important.

    Because the developers that I work with aren't accustomed to managing memory, we're constantly running into issues. We've got scripts that allocate dozens or hundreds of megabytes of RAM and don't free it when they're done. They'll go through 3, 4, or 5 more of these processes within a single script, not freeing memory they're done with along the way, so by the time the script is done running hundreds of megabytes that aren't needed are still tied up. Because the language can't be sure if data is going to be used again it hangs around until the script has finished running.

    Create dozens or hundreds of instances of one of those scripts and you've got a performance nightmare. Relying on a language or OS to do garbage collection will have the same net result.

Log in

Don't have an account? Sign up now