>If the amount of RAM available to the runtime is greater than the amount of memory required by a program, then a memory manager which employs the null garbage

>If the amount of RAM available to the runtime is greater than the amount of memory required by a program, then a memory manager which employs the null garbage collector (which never collects anything) is a valid memory manager. A bit of a tangent, but I wonder GC is one reason Android devices moved to larger RAM sizes faster than iOS did. (iPhone 5 == 1GB, GS3/N4/One == 2GB.) Under manual memory management or refcounting, running with RAM 90% full isn't slower than 50% full. (Your app code isn't slower, at least; who knows it if has effects via OS having less for cache or whatever.) But under GC, if 90% of RAM is full of live objects, you'll be forced to GC several times as often as you would if only 50% of RAM were full. So that 1GB->2GB bump might actually _more_ than halve how often you have to collect. There could be other reasons for the diff--maybe part of it is Android's more permissive multitasking model, maybe non-GC-related memory-use differences between Android/Java and iOS/ObjC, maybe greater focus on power consumption from Apple or greater focus on specs from Android handset makers.