> The mobile vendors have all gone with GC.

It's a minor point, but Apple created ARC specifically as a streamlined reference counting alternative to GC, which was never used in iOS and is now deprecated in Mountain Lion.

I do count ARC as a form of GC. The test is if the developer has to manually litter their code with calls to release/free memory.

You do not need to do so in Android (Java), iOS (ObjC), Windows Phone (C#) etc.

You're right. But on iOS, we still have to think about it a little bit. Maybe not with malloc and free (or retain/release, actually), but in terms of object graph (we can't have "retain cycles", or "strong reference cycles", as they are called in ARC).

It's a minor point and I agree with what you said, but I wanted it addressed in case someone who've not familiar with ARC gets the wrong impression :)

These terms have basic meanings that are independent of what you seem to wish they meant. GC is not reference counting, and it would benefit you to put he difference in your memory.

I've always seen "garbage collector" used as a generic term for an automatic memory management system, not a reference to the specific algorithm used to do it. It could be a tracing garbage collector or it could be using reference counting. Where are you getting the definitions that parent would benefit so from committing to his memory?

While some people might say reference counting is just a form of garbage collection, this blurs the useful distinction when discussing the overhead involved. Automatic memory management schemes that impose a variable runtime cost to analyze the object graph are simply totally unlike schemes that have no analysis step and thus no performance headaches. When people talk about GC being unacceptable for real time systems, they are not saying reference counting is unacceptable as well, they are simply saying that any system with a garbage collection phase are unacceptable. So that seems like a pretty clear split.

Reference-counting schemes don't have the same performance headaches as GC's with an analysis step, they have different ones:

* their own form of pause (when the last reference to a large tree of object disappears) -- this can rule out RC for real-time systems, while there are real-time GCs (though rare)

* a non-local memory access per reference creation (whereas in other types of GC, the cost of allocation can be reduced to a single increment and compare of a value probably stored in a register)

* none of the locality advantages of copying/compacting collectors

Personally I tend to see it as down to whether or not the developer is involved (which dovetails nicely with your reference to automatic memory management).

GC can be implemented via reference counting. But in my opinion, if the developer has to explicitly manage reference counting (e.g. by using "smart pointers" explicitly in C++) I tend to see it as distinct from GC.

Garbage collection seems to be a synonym for automatic memory management for many people. Some even see RAII in C++ as GC. I guess GC is so meaningful for many programmers as it is really convenient, that it has become the main word for AMM; as Google is to searching the web.

I am aware of the Wikipedia link. It also has no references, and is marked as being original content.

What term should we use to discuss garbage collection schemes that impose a real time overhead (those systems virtually everyone means when they say they dislike GC) and memory management schemes that involve no runtime overhead?

I agree: within the Android ecosystem and even within the ARM family, bytecode provides portability: you don't have to compile and distribute apps for different versions of the ARM architecture.

It's paradoxical however that to increase the portability of certain types of apps across mobile ecosystems, eg. iOS and Android, and now Ubuntu, your best bet can be to write the portable part in native C or C++, bypassing the Dalvik layer using JNI/NDK. This is apparently the common way to make cross-platform mobile games.

On memory consumption: I haven't made any measurements, but the Android .dex bytecode format has been designed with low space requirements in mind. See http://www.youtube.com/watch?v=ptjedOZEXPM . However, all apps run in their own VM process, with lots of common structures shared with them using an initial shared VM process and clever forking.

I always thought one of the main original motivations to use Java was because it's so well spread among developers. Since in the early days before the JIT compiler, there must have been a really obvious overhead even with the interpreter hand-coded in assembly. But they must have wanted to use a well known higher level language with good IDE support etc.

Ubuntu mobile apparently uses Qt: "It uses QML to give you a really slick, easy development experience for native apps with engines in C or C++, and JavaScript for UI glue that isn’t performance critical. We also give you full native OpenGL, which the top games companies are using to make incredible games." It seems actually pretty nice for developers: http://developer.ubuntu.com/get-started/gomobile/

ARM is currently dominating, but Intel has not given up yet. A high-level representation is still a good idea in my opinion.

MIPS is still around on Android, too.