They could have added garbage collection if they wanted to add as much ram to the iphone as the Android phones have but I guess they already made their choice long before one could develop code for the iphone.
Arguably far more important than the amount of RAM—which costs in dollars, battery, and sometimes even physical size—is the non-deterministic performance of GC, which directly costs in responsiveness.
> And GC is always less efficient than no GC, even with more memory.
No, it's not. GC allows for more efficiency in many scenarios. Imagine creating and destroying many small objects. With traditional memory management, every malloc incurs a cost to allocate a chunk of memory from the free store. This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for later restoring that memory to the block and possibly enlarging the block, merging with others, etc.
On the other hand, in a modern generational GC, a malloc typically consists of adjusting a single pointer to the nursery pool by the size requested.
Depending on the scenario, GC can be just as fast, or even faster. In other scenarios, manual memory management may be faster.
> This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for later restoring that memory to the block and possibly enlarging the block, merging with others, etc.
This manual work incurs a penalty only for the developer, not for the performance. And you get to fine tune your memory allocations to your program's behavior.
> in a modern generational GC, a malloc typically consists of adjusting a single pointer to the nursery pool by the size requested.
Sure, but by "less efficient" I'm not only referring to allocation speed, but also to memory usage. That nursery pool is auto-managed, and not program specific (with the exception of some smart gc guesses).
No, the work I described is not done by the typical developer. When's the last time you coded your own malloc ? Under the covers, though, malloc has to a lot of expensive bookkeeping of the sort I described that modern GC doesn't have to worry about.
And GC can be more efficient in terms of memory usage as well. Modern GCs compact and so avoid most loss due to fragmentation. Where malloc will generally leave blocks partially unused, GC can allocate objects consecutively with no space between them, even if the objects vary in size (though there may be loss due to alignment, but that loss will occur in any memory management scheme).
Just as a counter to your assertions - the code base I work on at work has its own memory allocation in it. It isn't the same as malloc, because all memory is allocated up front (and done by the caller, not the callee). There are no gaps in the memory (aside from those for aligning things nicely) and there is not really any way that you could make the memory usage any better in these regards (e.g. it is dense, and there is zero overhead after initialisation).
Garbage collected languages prevent this sort of thing from working, because they force overhead, and even though they might be able to do better than a lazy programmer, a person who cares about what they are doing will do ok.
Not necessarily. Especially not if you can program the cache (no idea if that is possible on an ARM processor).
The thing is that Malloc isn't particularly smart about how memory is allocated so you can end up with various tangles, etc.
On the other hand if you have enough memory you can do a hole world copy which, among other things, means that allocating memory is O(1). This is better than malloc if you have short lived and small objects.
If your available memory is less than five times the working-set size, GC is less efficient than some sort of malloc/free perhaps with reference counting
Where did you get this 5x number? As for reference counting, that's rather time-expensive, and does horrible things to the cache in multi-threaded scenarios.
The reference counting would only be used in certain cases where the dynamic extent of the object is unknown. Most objects can be cleaned up with an implicit management scheme like the RAII pattern in C++.
