I find it interesting that there was such an effort to reduce memory usage because I've always had severe memory issues on the two Android phones I've had.

The first, the myTouch 3G had about 100MB of RAM, with only about 25MB free from a cold boot, meaning the phone is really really slow due to memory pressure.

My current phone, a G2, has about 350MB of RAM total and about 70MB free on a cold boot (ICS).

A full Ubuntu Desktop install can use only about 250MB of RAM on cold boot and even Windows XP would run in 256MB of RAM.

So with so much emphasis on saving RAM, why is 350MB of RAM insufficient to run basically one app at a time on a phone (plus the various background processes the system is running)?

"Free memory" in a garbage-collected managed language is difficult to measure. If you don't have to GC, the performance-minded choice would to not GC. Every computation costs battery life, so I would suppose Android's GC is tuned to not run if it doesn't have to.

If you look at the specifications of system.gc(), it can be implemented as a placebo, like the "push to walk" button at the street corner. So even explicitly GC'ing isn't guaranteed to do anything.

Android also has a strategy for "swapping" components within a process, and whole processes. This is, effectively, Android's GC strategy across processes. An Android system's memory, especially on small-memory devices, should always look full-ish, but you can almost always launch a new task, since GC and components and process "swapping" (the "destroy" phase of component lifecycle) and GC can almost always make room for more.

> like the "push to walk" button at the street corner.

Thanks for using that comparison - oddly enough it provided some nice entertainment for me :D

Since I wasn't aware if "push to walk" was a cultural reference that I might not know I started some quick research that lead me to a couple of interesting articles.

I started off with a search that resulted in the Placebo Button (http://en.wikipedia.org/wiki/Placebo_button) article on wikipedia.

From the references section in that article I found a nice column from NY times about the street crossing buttons in NY (http://www.nytimes.com/2004/02/27/nyregion/27BUTT.html).

From which I picked up an interesting pattern in traffic control solutions - called the 'Barnes Dance'.

Which lead me to this video (http://www.streetfilms.org/barnes-dance/) from which I learned that it's also known as Pedestrian scramble (http://en.wikipedia.org/wiki/Pedestrian_scramble).

It's funny how a couple of well picked words on your side has lead me to an entertaining research.

I just wanted to say thanks and share this experience :)

I think the biggest problem with embedded GC is that you generally don't want to do pay the memory overhead that comes with generational algorithms. It's a pity that most Java systems are layered on top of some C-based OS, so that each process effectively has to have its own heap, with all the memory overprovisioning that entails.

Can you tell what you meant by "most Java systems"? Which are the Java systems that are NOT running on top of some C-based OS?

Managed operating systems such as JNode (Java based) or Singularity (.NET based) have managed kernels - everything is written in a memory-safe language. The OS can verify the memory-safety of a program in the loader (bytecode verification), so that there is no need for an MMU to implement process isolation; different processes can share the same heap. There is also a big performance advantage as process switching is essentially as fast as thread switching. IPC is typically done using message passing, but Singularity for example also allows processes to set up a shared memory space.

edit: relevant paper: https://agora.cs.illinois.edu/download/attachments/28320883/...

Thanks for this information. I am curious to see in which domain such Operating Systems will be used first. I am wondering actually why Google did not use such an OS architecture for Android (or Apple for their phones).

I have an older device with 256M installed that runs 2.2 and while it can slow down at times it does pretty well running opera, a mailer, navigation and google music streaming all in ram all on top of a bytecode vm. Lets not forget no swap space.

As a lark I just booted ubuntu 12.04 with mem=256M. It got to the greeter reasonably quickly, but it's been 10 minutes since i hit enter and I still haven't seen the desktop. I planned to launch chromium and thunderbird and report the swap used, but you get the idea. Its true that a lighter DE would be more usable, but I think you're looking at desktop RAM usage with rose colored memories.

PS: This is also why Android "task killers" are snake oil. You aren't low on resources. Let Java manage memory.

They're solidly useful for killing apps that don't play nicely with CPU/background services.

~25% of Android apps, at least games, are native applications, not Java apps.

All Android apps are subject to component lifecycle. Native code is no shield against a process getting reaped. The Android NDK provides lifecycle support even for all-native code apps.

The G2 (assuming you mean the T-Mobile G2/HTC Desire Z) has 512MB of RAM. It's actually surprising to me that it has that little free on a boot, though Android often sees the most memory pressure immediately after boot. For example, lots of applications listen to boot events and make sure that various alarms are still scheduled.

Are you saying Dalvik uses too little memory? Because I disagree from a consumer point of view. If they doubled the memory, Android phones would probably need 2 GB of RAM right now. So how can you say that?

> Dalvik in particular makes some fairly severe tradeoffs to reduce memory usage.

Out of curiosity, would you be willing to write a little blurb (or post a link) about those tradeoffs?

Here's Dan Bornstein's talk at Google I/O 2008 about the dex format and the original Dalvik interpreter: http://www.youtube.com/watch?v=ptjedOZEXPM I'm not sure how useful it is in comparing the Dalvik JIT to MonoTouch though.