
Introducing ART – A new Android runtime being introduced experimentally in 4.4 - alsutton010203
http://source.android.com/devices/tech/dalvik/art.html
======
jordanthoms
So this is why we haven't seen much happening on the dalvik side.

The source is here: [https://android.googlesource.com/platform/art/+/kitkat-
relea...](https://android.googlesource.com/platform/art/+/kitkat-release) and
commit log: [https://android.googlesource.com/platform/art/+log/kitkat-
re...](https://android.googlesource.com/platform/art/+log/kitkat-release) \-
So if somebody has the time to investigate it most questions should be able to
be answered.

~~~
rayiner
The guts are substantially different and seemingly more sophisticated. Notable
things:

1) The compiler under compiler/dex seems to do a pretty simple set of
optimizations and generate either code directly (compiler/dex/quick) or using
LLVM through an intermediate code called GBC (compiler/dex/portable).

2) There's a new file format, OAT. Contrary to some reports, it doesn't appear
to be a new bytecode, but rather a new file format for DEX bytecode. My guess
it exists to support features like caching generated native code or compiling
applications to images that don't have to be JIT-ed. The compiler has support
for writing out ELF files, and LLVM can load ELF files dynamically with
MCLinker.

3) There seems to be the start of a more sophisticated compiler under
compiler/sea_ir. My guess is that it's intended to enable more high-level
optimizations in the future. It seems to be a sea-of-nodes IR like the one
used in Hotspot's C2 compiler, but doesn't seem to be either finished or
plugged in. The change log suggests that it's still getting off the ground.

4) Judging by the commit logs, there seems to be a parallel-marking garbage
collector, though otherwise it doesn't seem to be anything fancy.

~~~
pcwalton
So I guess no moving GC still, because of LLVM. That's unfortunate.

Does anyone know whether Android/Dalvik has made decisions that lock them into
non-moving/conservative GC or whether it's still a possibility in the future?

~~~
djh_
Google made changes to how the JNI returns references to Java objects in Ice
Cream Sandwich (4.0) so that native code can work with a moving GC.

[http://android-developers.blogspot.com/2011/11/jni-local-
ref...](http://android-developers.blogspot.com/2011/11/jni-local-reference-
changes-in-ics.html)

Doesn't answer your question, just some supporting evidence.

------
fabian2k
Unfortunately that page doesn't actually explain the difference between ART
and Dalvik.

I found some random benchmark by a user on XDA ([http://www.xda-
developers.com/android/new-runtime-compiler-i...](http://www.xda-
developers.com/android/new-runtime-compiler-in-
android-4-4/#comment-1104912482)) that could indicate significant speedups
with ART. Though I would take this information with a huge grain of salt right
now as it is one benchmark from an unknown source.

~~~
Zigurd
As Android adds more features, more of Android is implemented in Java. Pretty
much all of Google Play Services is implemented in Java.

That means Android can rely less on the fact that graphics and the guts of
many UI widgets are native code under a thin layer of Java. Android was always
a "Java OS" but it has become more so since Android 3. So ART is important to
keeping Android quick.

Still, your mileage may vary. Unless you are doing significant computation in
your app, a synthetic benchmark will vastly over-emphasize the impact of a
better JIT.

------
devx
Someone benchmarked Dalvik vs ART, and it seems it's already 2x faster, and
the performance is much more consistent:

[https://docs.google.com/spreadsheet/ccc?key=0AnE-
DX9Fbr9KdFZ...](https://docs.google.com/spreadsheet/ccc?key=0AnE-
DX9Fbr9KdFZtRlhQaWxmVG5XdDR3TFR1Q3JONnc&usp=sharing#gid=0)

Since this is still probably in alpha mode, I assume it could get even faster
with further optimization.

~~~
prlin
Any explanation of the giant spike for ART? GC misbehaving?

------
scotth
Does anyone have information on what is actually _different_ about ART?

~~~
oscargrouch
Its a new compiler and VM, written in C++ instead of the Dalvik C, and with a
new runtime;

It looks that it can compile to two banckends: one called "Quick" and other
called "Portable"

I think "Quick" is a complete home backed Jit, while "Portable" is LLVM based

So probably (im guessing from fast source code study): This VM can JIT from
bytecode to native while running (the Quick backend) and can run a already
native payload using the LLVM backend..

The native payload probably will be very optimized since is AOT, and the
Quick, since is JIT will probably have lower optimizations (as a runtime
compiled code)

(and we can assume that, the Dalvik VM is getting obsolete)

Edit: adding more observations..

They have created a very sophisticated retargatable compiler that deliver into
a SSA based IR and from there it goes to the backends that i have cited
earlier

~~~
devx
If it's LLVM, that pretty much opens the door for running Native Client apps
on Android, and possibly even merging Android with ChromeOS, right?

~~~
oscargrouch
Thats a good guess.. theres a way to be sure of it..

The bitcode from Pnacl is different from the LLVM one..

But the "portable" backend naming scheme maybe could mean they will use the
PNacl-LLVM instead of the pure LLVM one..

I wonder how Chrome could glue with this.. but if the Nacl/Pnacl uses the
PPAPI api, in this hypotethical scenario they would replace the PPAPI runtime
with a runtime compatible with ART..

it can be done, and the final c++ application source code would look like the
java one..

edit: This could also mean the ndk applications will be first class citizens
and wont need to rely on a java shim + native bindings.. I think that is more
likely than the ChromeOS integration scenario

------
devx
If this is indeed the work of Flexycore, there are some explanations here,
although they don't go into a lot of details either:

[https://www.youtube.com/watch?v=tEAz9fRoDmA&list=UUowARqiVYk...](https://www.youtube.com/watch?v=tEAz9fRoDmA&list=UUowARqiVYkRt_Qb54CCtQWg)

~~~
Zigurd
Several have tried to "accelerate" Android, like Myriad with Turbo Dalvik, but
it's not so simple. The ART benchmarks are tantalizing, but how much battery
life do you give up to get 2X performance in a synthetic benchmark? Hopefully
ART is at least as efficient as Dalvik, but nobody outside Google has measured
that yet.

Potential improvements in the VM need to show they don't give up in other
performance dimensions what they gain in JIT'ed code performance.

~~~
ge0rg
Do you have reason to believe that by running code at twice the speed, the
energy consumption will be higher?

IMHO this will be absolutely compensated for by being able to switch into a
low-power state earlier.

~~~
Zigurd
I'd wager Hotspot's JIT would beat the pants off Dalvik's JIT, and make your
battery hot while doing it.

Dalvik's JIT is designed unlike other JITs: It is designed to JIT compile
_less_ code, but to find the code that has the highest impact. Dalvik's
bytecode interpreter already gains what Google has claimed is a 2X improvement
over interpreted Java bytecode. Before Android 2.3, that's how Android ran
code.

~~~
ge0rg
To really run a CPU hot, you need to manually create a workload that utilizes
all of the computation units (ALU, FPU, SIMD) interleaving assembler commands.
This is nontrivial, and will not happen "by accident" when doing aggressive
optimization. Have a look at the cpuburn program for one example.

~~~
ibrahima
For a mobile CPU, hot is a lot easier to achieve than on desktop/laptop.

------
jithesh
G had to do it. Compare Windows Phone 8 to Android - Dual core WP8 phones were
better or equal in performance compared to quad core Androids! Had compared
Lumia920 with SGS3 few months back.

~~~
vidarh
My pet peeve with Android is drawing apps. I bought a ZTE Open with FirefoxOS,
and the first thing that struck me is that the very first drawing app I tried
on a low end phone like that totally trounced every (I've tested at least two
dozen) drawing app I've tested on my far faster Android phone.

On every single one of them, the brush ends up lagging ridiculously far behind
my finger even with quite slow strokes, while on the FirefoxOS phone, I hardly
noticed the lag unless I did fast sweeps or used a stylus (there is lag there
but usually small enough that if using a finger, my fingertip obscures it)

------
pjmlp
So Google does acknowledge that Dalvik's JIT does not cut it.

------
bitwize
Pretty much tacit acknowledgement that Dalvik was a huge design mistake.

Funny how Apple got the runtime right in 2007 and now, more than six years
later, Google is still struggling with it.

~~~
amaranth
I know you're trolling here but I'm pretty sure Apple has gone through at
least two similarly large changes in their toolchain since launching the
iPhone. And this isn't the first change Android has had. Over time you figure
out better ways to do things.

~~~
dottrap
Actually, the iPhone Obj-C runtime has undergone very little changes since the
launch of the iPhone. Apple had already debuted Obj-C 2.0 (which was the most
significant change) in OS X 10.5 , before the iPhone launch.

Apple's clang/llvm transition was also already underway, but this had more to
do with building more integrated developer tools and not having to deal with
gcc, not as much the runtime.

ARC, perhaps the other big new thing you were thinking of, is again just a
developer tool that was enabled by the transition to clang. Fundamentally, it
is simply the compiler now being smart enough to inject retains/releases
automatically when compiling your code instead of you doing it manually.
Again, the impact of this is for developers, not end user (runtime)
experience.

------
wehadfun
So what is dalvik?

~~~
wmf
Dalvik is the JVM[1] in Android.

[1] Ignore the pedants saying otherwise; it walks like a duck and quacks like
a duck.

~~~
eropple
If it actually _did_ walk or quack like a duck, you'd be right--but it
doesn't. It does not support the Java bytecode format; this is why Groovy,
Rhino/LiveConnect, etc. don't work (and you can't do compile-time weaving,
further limiting it). It does not support a recognized class library profile.

There is a JVM specification and Dalvik does not conform to it: that means
it's _not a JVM_. It isn't pedantic to say that Dalvik isn't a JVM, because
it's not. RoboVM isn't a JVM, either. Supporting Java does not a JVM make.

~~~
Zigurd
> _this is why Groovy, Rhino /LiveConnect, etc. don't work_

You were doing pretty good up to there. The Android toolchain does not compile
to Dalvik bytecode. It translates from Java bytecode to Dalvik bytecode. So
any language that compiles to Java bytecode _could_ be used to write Android
apps.

There are many projects to bring other JVM languages to Android.

~~~
eropple
I am well aware of how Android's dexer tools work and that non-Java languages
work on Dalvik; I use Scala on Android regularly. groovyc builds legal Java
bytecode and (as of 2012, at least--since the advent of dexmaker this may have
changed) fails when you try to run the dexed output on Android (RTCG). Rhino
_will_ work as an embedded runtime on Android with optimizations disabled--in
which case it runs in fully interpreted mode--but fails when you enable
optimizations or when you attempt to use LiveConnect (runtime class
construction).

And this is because Dalvik doesn't understand Java bytecode. It's not
conformant to either J2SE or J2ME and these are examples of libraries that
puke because of its nonconformance. That's all I'm saying.

~~~
Zigurd
I think you are mixing up a couple things here: Converting JVM languages that
result in bytecode sequences that dex or Dalvik would never otherwise see in
their test suites could uncover bugs. Since all that is open source, and
unlikely to rank high on Google's priorities, the answer is to fix those bugs.
Unless you mean to say this somehow falls outside Dalvik's coverage of Java
semantics.

Other things, like loading Java bytecode dynamically at runtime are
limitations of not using Java(TM) bytecode.

~~~
eropple
Perhaps I'm not being clear. Groovy and Rhino emit bytecode that translates to
Java at compile-time. Their runtime code generation facilities crash on Dalvik
_because Dalvik does not support runtime-generated, JVM-compatible code_.
Dalvik does not support legal J2SE operations because it doesn't support Java
bytecode as per the JVM spec.

I am not saying that Dalvik is bad. I'm saying it isn't a JVM; I was using
this as just one example of its not-JVMness.

~~~
ixampl
Was just wondering... for Groovy couldn't they just bundle the tooling to turn
the runtime-generated bytecode into Dalvik bytecode? If there were a reliable
Dalvik bytecode to JVM bytecode translator I assume most of the issues
(similarly occuring with libraries like Javassist etc.) associated with load
time and manipilation and code generation could be resolved. Or are there
other special limitations on classloading in Android?

~~~
vorg
> for Groovy couldn't they _just_ bundle the tooling to turn the runtime-
> generated bytecode into Dalvik bytecode?

There's no "just" when it comes to the Codehaus implementation of the Groovy
Language. According to the Codehaus Groovy project manager [1], "Groovy is not
able to run properly on Google's Android mobile platform ... (It takes) 20
seconds to start up a simple Hello World".

BTW, that webpage was seeking students to do work making Groovy run on
Android, but Google didn't accept that project, or any projects related to
Groovy [2], perhaps because no students were interested or maybe because of
Codehaus's history of mishandling GSoC projects. The last Groovy project ever
accepted was one in 2011 rewriting Groovy's antiquated parser in Antlr 3.0.
The project failed and Google only paid out half the project money.

[1]
[http://groovy.codehaus.org/GSoC+2013](http://groovy.codehaus.org/GSoC+2013)

[2] [http://www.google-
melange.com/gsoc/projects/list/google/gsoc...](http://www.google-
melange.com/gsoc/projects/list/google/gsoc2013)

------
wmf
What a tease!

------
AsymetricCom
I can't wait for someone else to invest effort in making this a stable and
secure runtime!

------
donpdonp
With a hostile owner of Java, it seems strategic to begin porting to a new
runtime. I'm a little surprised its written in C++ and not go. Every step away
from the JVM instruction set and disk formats is a harder case to make for
patent/copyright infringement.

~~~
mscottmcbee
Go is still very young. Doesn't make sense to write such a critical piece of
software with it quite yet.

~~~
nl
Google have some pretty critical software running on Go already (and have for
a couple of years now). For example, their MySQL scaling proxy[1] is in Go.

[1] [https://code.google.com/p/vitess/](https://code.google.com/p/vitess/)

~~~
vidarh
But it is very different to use something server-side in your own environment
where you can deploy updates easily, vs. client side on devices where the
wrong kind of bugs can wreak havoc for millions of uses and make updates to
fix them extremely much more complicated.

