
Dalvik JIT - davidw
http://android-developers.blogspot.com/2010/05/dalvik-jit.html
======
stcredzero
Android has a big fundamental advantage over iPhone OS: Garbage Collection.
This is generally considered to be 30-40% overhead on debugging time.

~~~
dschobel
It's still amazing to me how powerful these devices have become that you can
put a GC on a mobile platform, especially considering how sensitive users
would be to GC stalls causing unresponsive user interfaces.

~~~
samstokes
I'm pretty sure modern garbage collectors don't have that "stop the world"
behaviour that causes unresponsiveness. And tens of millions of J2ME-capable
phones have been running garbage collectors for years. (And while J2ME has a
reputation for slowness, that's mostly about startup time, and anyway it's
largely due to bad coding rather than the runtime being inherently slow. Opera
Mini and the J2ME version of Google Maps are both more responsive than many
"native" apps.)

~~~
ori_b
Many of them do have stop-the-world GC. A well implemented stop the world GC
allows higher throughput, at the cost of increased latency. This is especially
the case when provably-local allocations can be put onto a thread-local heap,
and you only do stop-the-thread GC on those. So, in the absolute sense, stop-
the-world GC overhead is lower than incremental, low-latency GC.

But yes, we have GC that is fairly responsive these days, too, for when
throughput isn't the driving concern.

------
plesn
Does someone have a link to the video he is talking about from the Google I/O
conference ?

~~~
indy
I don't think the Google I/O 2010 videos have been released yet. They should
be coming out in the next few days though.

------
openfly
Dalvik is all that is wrong with android. If they removed Dalvik, the app
store for android would suddenly go from zero to hero. I don't understand why
google made such a horrendous and really obvious mistake in using dalvik. It
doesn't make any sense at all.

~~~
andybak
A bit more substance to your complaint would be great. What are you arguing
for? A normal JVM? Native code? A WebOS style environment?

There are trade-offs to all decisions. Dalvik performance has been tolerable
and now it looks like it has progressed to being quite reasonable.

I'm just waiting for a chance to use a nicer language to produce Dalvik byte-
code. I don't think it's very friendly to dynamic languages but I'd settle for
almost anything other than Java.

~~~
tumult
It's not unfriendly to dynamic languages, but it's unfriendly to things which
allocate and deallocate frequently. The JVM is actually pretty ok at this
(Clojure for example), my understanding is that JVM can deal with short-lived
heap objects decently, whereas Dalvik is very slow for anything other than the
stack.

~~~
bad_user
In a dynamic language you allocate/deallocate stuff more frequently,
especially considering how classes/functions can and are getting changed at
runtime. Also if you want late binding you have to generate stuff on the fly
(like having call-site caches) if you want a decent performance.

From what I understand Dalvik is also slower for anything involving
java.lang.reflect.

So Dalvik is kind of unfriendly to dynamic languages for now. That's OK ... I
wish there was some alternative to Java. Scala sucks IMHO.

~~~
tumult
You're wrong. I can write Lua, Python or Ruby code that does little allocation
and would perform well (in a relative sense) on Dalvik. Those are all dynamic.

I could not write Haskell or OCaml code that performs well on Dalvik, because
of their allocation profiles.

A language being dynamic does not have much to do with its allocation profile.
Haskell and OCaml are not dynamic languages, but have allocation and
deallocation profiles that grossly outstrip what you would see in typical
Python or Ruby code.

Scala allocates most things on the heap and is probably unsuitable for use on
Dalvik. What is your complain about Scala as a language?

~~~
bad_user
> _I can write Lua, Python or Ruby code that does little allocation and would
> perform well (in a relative sense) on Dalvik. Those are all dynamic._

You MISS the point ... because everything can change, the semantics are
different. A class can change ... first it needs to be garbage-collectible,
with one way to do it being for every class to be loaded by a different class
loader. Then the methods themselves can change, so in JRuby every method on a
class has a corresponding method handler (another class at the VM level).

Even if you write code that doesn't do much, you're programming in Python, not
RPython, or in Ruby, not in Duby. You may use a subset of the language, but
the interpreter has to be prepared for everything.

I have been following the developments in the JRuby project, and I sincerely
doubt that you can write efficient Ruby code on top of Dalvik ;)

> _A language being dynamic does not have much to do with its allocation
> profile._

Again you miss the point ... it does have to do with its allocation profile if
you're doing shit that doesn't match the JVM type system. And yeah ... Haskell
and Ocaml both have type-systems much more different than those of
Ruby/Python.

> _Scala allocates most things on the heap and is probably unsuitable for use
> on Dalvik_

So do JRuby or Jython ... AFAIK they don't do tracing compiling, and the JVM
doesn't do custom stack-allocated values ... again, hard to match the JVM type
system.

On the other hand, Scala uses Java's call semantics, so the generated bytecode
is efficient because for runtime-dispatch it follows Java's rules. In a
language like Ruby or Python with its own rules about what to call, you need
techniques like call-site caching implemented by the language author ... see
<http://en.wikipedia.org/wiki/Inline_caching> ... one issue meant to be solved
by InvokeDynamic (whenever Java7 ships).

> _What is your complain about Scala as a language?_

Too many features thrown in there, some non-orthogonal, just to please the JVM
... and I'm tired of languages with a complex syntax that don't provide a way
for library authors to hook in the compiler's pipeline ... you get the worst
of both worlds (unreadable code / not capable enough).

I just want a syntax tree from some expression, which would enable me to
work/use something like LINQ, or adding to it new syntax when you need it
(have a look at Perl's MooseX to see what that can do).

Is that so hard, especially for a language that comes with tons of other
features, some of them improperly implemented? (IMHO, type-erased generics in
a runtime-dispatch language are totally useless / thrown in there only to have
local type inference ... and those manifests are just an ugly hack).

But I already said, it's my opinion ;)

