Dalvik JIT | Hacker News Reader

Dalvik JIT

android-developers.blogspot.com

34 pointsdavidw27 comments

Android has a big fundamental advantage over iPhone OS: Garbage Collection. This is generally considered to be 30-40% overhead on debugging time.

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.

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.)

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.

It's still amazing to me how powerful these devices have become that you can put a GC on a mobile platform

Really? Colleagues have told me of applications using GC that ran on 486 with good performance.

The popular notions of what dynamic languages and GC are like are literally decades out of whack. This is a self perpetuating phenomenon, which is why you can have popular languages that are between 1 and 2 orders of magnitude slower than they should be. (Outdated GC being a prominent factor.)

I remember the GC stalls being quite apparent for swing applications which I wrote in undergrad back in the 2000 to 2002 time frame (so it must have been java 1.3).

Highly responsive UI and relatively low system memory (256MB on the G1) just strikes as quite the feat on top of a GC language. Although you're right, I may just be dating myself.

Back in 2000, Java VMs were still lagging behind Smalltalk VMs, especially in real-world performance.

OTOH, you can still leak memory in Android by holding references to unneeded resources, particularly Contexts.

http://android-developers.blogspot.com/2009/01/avoiding-memo...

It's a different sort of problem, but you have to be careful either way. There is a subtle benefit to having been forced to manage reference counts.

This is a problem in all GC environments, but the amount of effort required to avoid that (exceptional) situation is an order of magnitude less. There is still a big win for GC.

I've heard from some people that garbage collection is the reason Android scrolling is never quite as smooth as an iPhone. I don't know if that's true, but if it is, I'd rather just manage my own memory. It's really easy once you get the hang of it. Header files are more of a pain to me than memory management is.

It's really easy once you get the hang of it.

You are 100% with memory management? The problem is not the 99.99% of the time when you do it right. It's the other time when you do it wrong, and debugging that.

Have you actually tracked the time/effort? Can you quantify what memory leaks are costing your project?

I'm not saying that it's easy, or that it doesn't take any time or effort. But if garbage collection makes your app scroll like crap, then the effort is probably worth it, don't you think?

That's a pretty naive assumption about the uniformity of GC performance across all implementations and algorithms.

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

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.

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.

What's wrong with it? Are you saying that because if they had a more standard JVM they could run all those "great" J2ME apps? No thanks.

A problem with the JVM that is that handsets would need to license the JVM bytecode technology from Sun (Oracle), if I understood things correctly. So dalvik works around that licensing fee.

Otherwise I am pretty sure that there will be a lot of "great" android apps to be ironic about as well.

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.

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.

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.

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?

> 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 ;)

Hecl works fine on Android.

Is it in active development? A quick google doesn't find anything newer than a few years old.

Yes, it is. I'm kind of hoping I can get a phone (Google guys: hint hint!) to really get into it though.

Duby (http://github.com/technomancy/ohai-android) seems to be showing a lot of promise

Reply on news.ycombinator.com