ART project —

What is ART? We’re not sure… yet

Change in Android 4.4 could mean that the Dalvik runtime may have met its match.

Android 4.4 KitKat has brought several changes to Google's mobile OS, but one mysterious addition is drawing significant attention. Tucked inside the developer menu is a new runtime option: Android Runtime (ART). Looking over the limited documentation on the feature doesn't give away much, but a report from Android Police has some interesting details.

To understand what ART may do, we need to discuss how things work now. At the heart of Android is the Dalvik runtime, which uses a just-in-time compiler to translate bytecode into instructions that can be run on the available hardware.

According to Android Police, ART takes a different approach to compilation, and it's an approach that could have serious performance and battery life advantages. ART will take the same software packages from the Google Play store and compile them during the installation process. The operating system then simply runs the ART-compiled software as it's stored. Not having to waste compute cycles on compiling bytecode every time you open an app should generate some improvements to responsiveness and battery life.

ART might offer a performance gain in other ways, too. Dalvik's strength was that the code it generated could be run on all types of hardware, an important factor when you consider the number of platforms that run Android. Dalvik's weakness was that the code wasn't necessarily optimized for that hardware. By compiling the software at installation, ART may be able to focus more on optimizing the code generated rather than simply generating code as quickly as possible.

It's possible that the runtime's presence is simply a proof of concept, testing the consistency with which ART-compiled software performs as expected without optimizing the code any further. And it's important to remember that all of this remains speculation until Google decides to share more information about its plans for ART.

It feels faster, but some applications like Titanium Backup crash when starting if ART is enabled.

gcc -O3 --enable-unsafe-optimizations or something.

Overall things seem generally quicker and smoother with it enabled. The optimizing applications stage takes forever and a day when you enable it, so it's clearly doing something more than the normal runtime.

Responsiveness and battery life are still my two biggest knocks on Android. Anything to boost the two is a huge win.

Have you used android 4.2 or newer?

No, but I'm looking forward to getting 4.3 on my GS3 when it releases for AT&T on the 13th. Hopefully it will squash the random battery drain thing my phone has going on with it that can only be stopped by turning off and back on.

So for stuff that does a lot of java (and not much GPU, system library, etc) it is indeed a whole lot faster, I guess because its a real compiler whereas the JIT in Dalvik does almost no optimization, has no real ability to use ARM NEON, etc.

This seems like it'd be an extremely long install time for medium-large apps, unless things were compiled in the cloud or something.

I guess the question is, would you accept longer install times for better battery life and responsiveness going forward?

Personally, I would gladly accept that, but I can see how some people could get annoyed having to wait for their shiny new app to install.

Maybe I'm missing something, but I suspect the compilation is going to have to take place on every update as well (unless the compiler has some means of detecting which classes have been changed). Given the rate of updates (which is a good thing), your phone is going to be spending a fair amount of time recompiling in the background. It might be useful to be able to choose which apps get the ART treatment (keep the core apps that you use a lot compiled, but leave other junk you open once a month on Dalvik). Alternatively: do the compilation on Google's servers up in the cloud and download the relevant version ready-to-use.

This seems like it'd be an extremely long install time for medium-large apps, unless things were compiled in the cloud or something.

I guess the question is, would you accept longer install times for better battery life and responsiveness going forward?

Personally, I would gladly accept that, but I can see how some people could get annoyed having to wait for their shiny new app to install.

Maybe I'm missing something, but I suspect the compilation is going to have to take place on every update as well (unless the compiler has some means of detecting which classes have been changed). Given the rate of updates (which is a good thing), your phone is going to be spending a fair amount of time recompiling in the background. It might be useful to be able to choose which apps get the ART treatment (keep the core apps that you use a lot compiled, but leave other junk you open once a month on Dalvik). Alternatively: do the compilation on Google's servers up in the cloud and download the relevant version ready-to-use.

Dalvik was trace-based so that only parts of APKs that were run frequently were JIT'ed, while the rest might be interpreted. I guess they could do something similar here where they reserve full optimization for a subset of methods.

FWIW, recompiling all the APKs on my phone (170) took about 20 minutes with the current version of ART. Thats about 7 seconds on average, although large complex apps might take much longer.

This seems like it'd be an extremely long install time for medium-large apps, unless things were compiled in the cloud or something.

I guess the question is, would you accept longer install times for better battery life and responsiveness going forward?

Personally, I would gladly accept that, but I can see how some people could get annoyed having to wait for their shiny new app to install.

You could also, for example, have it so that the app is available for immediate use using Dalvik, then compile it at low priority in the background (possibly only when the device has external power, to avoid the battery life impact). Immediate new shiny, plus speed improvements in the long run.

Responsiveness and battery life are still my two biggest knocks on Android. Anything to boost the two is a huge win.

Have you used android 4.2 or newer?

Yes, I have. They are certainly better. Still not as good as iOS. I can't go a full day without charging phone. Barely half of one.

Granted, this is on a galaxy nexus. Perhaps newer phones are better.

I could get 2 days on the Galaxy Nexus, although with a custom kernel. It entirely depends on your use and apps, moreso the apps. An app like OS Monitor can show interesting things, like Facebook staying at 10-20% CPU use when not open.

Responsiveness and battery life are still my two biggest knocks on Android. Anything to boost the two is a huge win.

Have you used android 4.2 or newer?

Yes, I have. They are certainly better. Still not as good as iOS. I can't go a full day without charging phone. Barely half of one.

Granted, this is on a galaxy nexus. Perhaps newer phones are better.

Galaxy Nexus is just horrible when it comes to battery. I basically had to charge every day when using GNexus, but with S3 and presumably other similarly speced phones I can last for 1.5 or maybe even 2 days.

Maybe I'm missing something, but I suspect the compilation is going to have to take place on every update as well (unless the compiler has some means of detecting which classes have been changed). Given the rate of updates (which is a good thing), your phone is going to be spending a fair amount of time recompiling in the background. It might be useful to be able to choose which apps get the ART treatment (keep the core apps that you use a lot compiled, but leave other junk you open once a month on Dalvik). Alternatively: do the compilation on Google's servers up in the cloud and download the relevant version ready-to-use.

Exactly. When it goes into production it will almost certainly work in a similar way to Microsoft's MDIL on WP8. So that the bulk of the code (typically around 80%) is precompiled, and the remaining code is compiled to an intermediate representation for fast relinking and fixup. ART apparently already has two compilers as it is, Quick and Portable, and a third may be in the works. ART as is is not the finished article, it's good enough for testing, but what Google puts into production will likely work at least as well as Microsoft's solution to this problem.

Given the rate of updates (which is a good thing), your phone is going to be spending a fair amount of time recompiling in the background.

This reminds me of my days running Gentoo Linux where stuff was constantly compiling in the background.

Google are going to have to do everything they can to avoid that issue for obvious reasons. ART right now is a really opportunity for developers to find out what will break, when it goes into production I expect the side-effects to be barely noticeable.

This seems like it'd be an extremely long install time for medium-large apps, unless things were compiled in the cloud or something.

I guess the question is, would you accept longer install times for better battery life and responsiveness going forward?

Personally, I would gladly accept that, but I can see how some people could get annoyed having to wait for their shiny new app to install.

You could also, for example, have it so that the app is available for immediate use using Dalvik, then compile it at low priority in the background (possibly only when the device has external power, to avoid the battery life impact). Immediate new shiny, plus speed improvements in the long run.

I think this would be the ideal. Maybe Dalvik immediately and set aside a scheduled time to switch to ART, like 3-6AM while plugged in or something simple like that.

In other words: They really wish they had used .Net all along instead of Java. This is exactly how .Net works. Rather than constantly re-translating bytecode, it compiles the bytecode into native code once (either during install or on first execution) and then runs the native code from then on. I've never understood why someone would go with JIT over compile-once.

There are all sorts of reasons to prefer one or the other. Issues such as forward compatibility, optimisation, verification, energy costs, security, protecting the source code, the flexibility of intermediate formats, the amount of resources expended on compilation, all come in to play. There is no one right answer.

It's entirely possible that even when ART goes into production, if it does, that Google will also maintain Dalvik as well, and thus support interpretation and JIT (Dalvik), hybrid AOT (ART), and native code (NDK).

People have been arguing about this sort of thing for 60 odd years, we'll be arguing about if for many more.

Rather than constantly re-translating bytecode, it compiles the bytecode into native code once (either during install or on first execution) and then runs the native code from then on. I've never understood why someone would go with JIT over compile-once.

Compile at first execution is one type of JIT. I think actually Dalvik does cache JIT code too, but thats not really the point. Its actually only JITing some parts of each program in order to save memory. Infrequently run routines may not be compiled at all. Its a different set of goals then you're thinking.

In other words: They really wish they had used .Net all along instead of Java. This is exactly how .Net works. Rather than constantly re-translating bytecode, it compiles the bytecode into native code once (either during install or on first execution) and then runs the native code from then on. I've never understood why someone would go with JIT over compile-once.

Downvoting shouldn't happen just because you disagree with him folks.

In any case, .Net wasn't really an option when Android was getting started. Remember, .Net started as a Microsoft technology and there was no way that was running on ARM. Mono has come a long way, but there are still parts of .Net it doesn't support, and back then that was not a safe bet to base your entire platform on a project to port another vendor's spec.

But in any case, they would have had to write the Compile-Once JIT themselves, because they have their own custom APIs. They are doing it now with Java, so it isn't too different.