
A Closer Look at Android RunTime in Android L - rohan404
http://www.anandtech.com/show/8231/a-closer-look-at-android-runtime-art-in-android-l
======
flohofwoe
It's interesting that an asm.js Javascript application running in a web
browser yields better performance on Android then a Java application running
on Dalvik:

[https://blog.mozilla.org/javascript/2013/08/01/staring-at-
th...](https://blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-
dalvik-vs-spidermonkey/)

So ART and AOT compilation is a step in the right direction, but I'm secretly
hoping that Google will enable Portable Native Client 'natively' on Android
outside the browser for proper C/C++ development. Distribution format is a
frozen LLVM IR subset, final compilation to the CPU architecture happens on
the client side, and performance is close enough to pre-compiled that the
difference doesn't matter much.

~~~
pjmlp
I would just be happy if little things like SKIA and SQLLite were exposed in
the NDK, instead of forcing us to bundle our own versions.

And having a gdb setup that works properly.

------
sandGorgon
Here's a question - has Google made the move to ART for performance reasons or
is it because it makes it possible to move to ... say.. Golang for Android ?

Let me explain - One of the big reasons that Google cannot switch over to
Golang (or Dart, or any other) is that the core of Android SDK is written in
Java and therefore every app needs to work with Java to be able to tap into
it.

However, ART can make it possible for SDK components to compiled down to
object code, thus making it possible for Golang/Dart/etc. to link against it,
while MAINTAINING backward compatibility with old java apps.

Will it allow new apps to be written in pure native code, without relying on
the JNI bridge ?

~~~
izacus
ART is still Java runtime which conforms to Java memory model, GC requirements
and everything that comes with it.

So no, you cannot just link random other languages without going through JNI.
That is a common misconception. Also most of Android itself is managed Java
code, so making other languages first-party citizens would require pretty much
full OS rewrite. I very much doubt rewriting whole Android just to support
non-JVM languages is worth it.

Making ART VM fast, efficient and adding Java 8 bytecode compatiblity is I
feel a much better use of development time. Wasting precious development time
to placate devs that don't want to switch languagaes is - I feel - a hugely
wasted effort.

~~~
higherpurpose
I _almost_ wish Google loses against Oracle at the Supreme Court, and is
forced to pay Oracle _billions_ every year as long as it continues to use
Java, just so it's forced to switch away from Java. Almost, because I know
Google losing that lawsuit could mean dire consequences across the industry.
But it's still annoying that Android has to use Java and can't change away
from it.

~~~
WildUtah
Clearly a win for Oracle would be a horrible disaster for the industry and
freedom of speech. It would also be a huge relief and benefit to Android
programmers once it forced Google to switch the platform to a less awful
language.

~~~
danieldk
What stops you from using Kotlin, Scala, or other languages that are available
for Java VMs?

~~~
cwyers
This gets asked pretty often around here, and the answer (IIRC) is that in
order to use any non-Java JVM language on Android, you have to link in a lot
of libraries, and you start running into limits that Android puts on how much
stuff you can pack into an executable.

~~~
izacus
While mostly true, use of Kotlin has been rather nice with IntelliJ. Standard
library is very small and out-of-the-box IDE support with Gradle plugin helps
alot.

------
ShabbyDoo
For Google, ART seems bigger than just Android. Consider the degree to which
their infrastructure depends on the Oracle JVM and the associated strategic
risk. As one datapoint, recall the Oracle vs. Google Java lawsuit. How much
additional ART development effort is required for correct execution of non-AWT
(Abstract Windowing Toolkit) Java applications (essentially, headless server
processes)? I know the Java/JVM ecosystem well, but I have not done any
Android development. Surely, Google wants control over the destiny of its core
software stack.

The article doesn't mention one seemingly huge benefit of JIT compilation:
profile-guided optimization:

[http://www.slideshare.net/ZeroTurnaround/vladimir-
ivanovjvmj...](http://www.slideshare.net/ZeroTurnaround/vladimir-
ivanovjvmjitcompilationoverview-24613146)

Perhaps the baby has been thrown out with the bathwater?

Little is mentioned about how ART compares to the JVM. For example, does ART
perform escape analysis? Not all object allocations are equally bad. The Sun
JVM can figure out which objects may be allocated on TLABs (Thread Local
Allocation Buffers) - an optimization which reduces the burden placed on the
garbage collector because TLAB-resident objects may be deallocated as the
stack is popped. [Please fact-check me as I'm merely a long-time Java
developer vs. an expert on JVM internals]

~~~
pjmlp
Well, OpenJDK is getting AOT compilation as well (planned for 9). In addition
to JIT.

The SubstrateVM is the AOT compiler for Graal.

And many commercial JVMs do offer AOT compilation.

Also, .NET has had AOT/JIT since the very beginning. And now static
compilation is coming as well.

~~~
logicchains
> Well, OpenJDK is getting AOT compilation as well (planned for 9). In
> addition to JIT.

On ARM? Last time I checked, OpenJDK doesn't even have JIT compilation on ARM,
it just interprets the bytecode.

~~~
pjmlp
> On ARM?

Well, at least the closed source JDK has it. As many other commercial JVMs.

As for AOT, it was referenced at Java ONE, Java Language Summit and Øredev
2014.

------
andyjohnson0
_"...an application’s first start-up will be much increased compared to an
equivalent Dalvik system."_

Any thoughts on why they they are compiling to native on first run, rather
than at install-time?

Often a user will want to run immediately after install, but my feeling is
that people are less likely to be frustrated by a longer install time than
having to wait for an app to start-up.

Edit: Izacus and InclinedPlane say that AOT compilation is at install-time and
the article is wrong.

~~~
ohazi
> Any thoughts on why they they are compiling to native on first run, rather
> than at install-time?

Or why they don't do it on the server so that you get the specialized binary
directly from Google Play? Why should my phone be compiling anything?

~~~
izacus
Because Android ecosystem isn't locked down to a single app store that would
prepare binaries for all 8000+ devices with several hundred different SoCs.

The device itself is by far most capable of choosing optimal compiler
optimizations for it's own SoC.

------
neals
Not an Android Developer here. Is there no "pauseForGC" function in
Java/Android? I know AS3 has it, and you can use it to suggest GC at a point
where there aren't any animation going on.

~~~
rohan404
There is a System.gc() call which is essentially what you described, but it
doesn't help with allocations freezing the UI for memory intensive
applications

------
frozenport
This article is a great reminder that garbage collection should not be the
default strategy as it is hard to get right, Dalvik is almost a decade old,
and that it introduces performance issues which are not transparent to the
programmer. Indeed these second long delays have rendered Android hardware
second rate.

~~~
rohan404
It was pretty ridiculous, even on some of the most powerful hardware out there
I still found animations to lag from time to time due to the GC_FOR_ALLOC
calls! Ended up with a bunch of hacks to try to work around the issue, but
none fully resolved it.

~~~
on_and_off
If animations lag because of allocations, then you are allocating too many
objects.. The most common cause is object allocation in a critical part like a
draw call (or view binding).

~~~
rohan404
This is true, but for operations like loading images from disk for example,
this is unavoidable. The best you can do is reuse memory instead of allocating
whenever possible

~~~
kuschku
On Android you should definitely load the images Async and not load them
within the draw call.

~~~
rohan404
Even loaded asynchronously, the calls for allocation still cause lag. Unless I
am doing something incorrectly?

~~~
on_and_off
You can use inBitmap in order to reuse bitmap instances instead of of
allocating new objects. If it fits your use-case, Glide is a very modular lib
that implements inBitmap. It is true that you will always have to create some
objects though. For example with Glide, a DataFetcher is created with each new
image request. You should do your best to keep it at a minimum though, with a
focus on creating heavy objects only when it is absolutely necessary.

Other than that, lag can come from many things, so if you lag without GC, the
only solution is to profile that part of your app.

------
jkn
The URL points to the second page of the article, can someone fix it?

~~~
fpgeek
That's because the original submitter wanted to highlight the garbage-
collection discussion, not the whole article. Of course, now that the title
has been changed...

------
pjmlp
It was about time Android catched up with how iOS and Windows Phone work (e.g.
everything is AOT compiled to native code).

Now it just needs to provide a similar developer experience to the other
mobile platforms for the C and C++ developers.

~~~
djur
As I understand it, the major speed improvements with ART come less from the
native compilation than from the improved GC and the ability to do whole-
program optimizations during the AOT compilation step.

EDIT: Also, ART takes a different approach to AOT compilation than either iOS
and Windows Phone. iOS apps are shipped as compiled binaries from the start,
and apparently Windows Phone apps are compiled in the cloud by MS. ART does
the native translation step on the device itself, which has only really
recently become feasible with the speed and storage capacity of recent Android
devices.

~~~
higherpurpose
I think his main point was that it has caught up with the _performance_ of
AOT, not the nitty gritty details behind the process, which is kind of
irrelevant to the user.

~~~
danieldk
It is relevant to the user for two reasons: portability and speed. In contrast
to iOS, Android in the wild runs on everything from ARM to x86, in many
different generations. Doing the compilation on the device allows the AOT
compiler to optimize for the specific CPU that the device uses. Also, it
increases compatibility, because what is shipped is platform-independent
bytecode, not a binary that may only target one specific architecture.

~~~
pjmlp
This is a solved problem since the early 80's, known as fat binaries or
delivering multiple binaries in a package.

I code mainly in C++ (NDK) and don't have any issues delivering code.

~~~
danieldk
_This is a solved problem since the early 80 's, known as fat binaries or
delivering multiple binaries in a package._

No, they are not the solution: you cannot provide new optimized versions for
generations that did not exist yet when you compiled the binary. Also,
providing an optimized version for every ARM, x86, etc. generation will make
the binaries very fat.

Fat binaries worked for relatively static platforms, such as Macs. For devices
which are (still) iterating quickly, it's a suboptimal solution. Sure, it
works for delivering code, but it is suboptimal.

(Not that I believe that ART is currently optimal, e.g. it should not be
necessary to do the compilation of an app on 1 million devices that are
identical.)

~~~
pjmlp
They are only fat at the store, the devices only see the .so they understand.

And it isn't that hard to have "APP_ABI := all" in Application.mk. The build
just takes a little longer on the CI system.

~~~
izacus
There's currently more than 100 SoCs out there and several major generations
of ARM architectures which show clear benefits of GCC compiler tuning for
their platform.

Tracking all those devices and architectures is dumb, when the
manufacturer/device can provide proper tuning for the device itself.

~~~
pjmlp
Yes, but my experience tells me that "can" != "he/she will".

