I'm curious why iPhone can't page application memory out to persistent storage (whatever of that 16GB etc you're not using for music) when they're in the background and RAM runs low. That would be the ideal - frozen background apps saved to persistent storage until needed without sitting in RAM.
I'm assuming the OS is modern enough that all apps have their own address space so perhaps the hardware doesn't have an MMU capable of the necessary remapping of physical memory into a different address space.
Oh and two nits with Grubers piece. 1) This system is well thought out but it's hardly "state of the art" and 2) on iPhone OS 4.0 backgrounded apps will receive a willTerminate notification before they're completely terminated.
When an app is swapped to disk, all it's code and data pages are stored. When it's resumed, the code and data pages are loaded back. This isn't so terribly different from relaunching the application (loading the code) and having the app restore it's state (loading the data). In fact, the app can even be more efficient in saving it's own state because it can discard anything it knows it doesn't need.
Paging is really only necessary if you can interact with more than one application at time. On an iPhone, that doesn't happen. Paging is probably less efficient than this system.
Paging is a technique to free up RAM. Whether its used to enable interaction with multiple apps, to allow a single app access to more memory than physically exists, or to allow more apps to be frozen in the background is irrelevant. It is neither better nor worse than the system Apple has designed. Its just different.
And yes, an app can manually attempt to restore it's state but a) doing so can be quite tricky (keyboard up, word half-typed) and b) it's puts a heavy onus on developers, many of whom just do not bother.
Of course, then you have to deal with resources – like when you unfreeze your app partway through typing a word, but in the meantime the user has changed keyboard layouts, or you unfreeze the camera program but meanwhile something else has been using the camera and left it in a different state.
Better to persist as little as you need, and deal with everything else through clearly defined lifecycles, IMO. Although, I also think programming languages should provide immutable datatypes by default ;).
Good points - except that under iPhone OS 4.0 the OS and apps already have to handle these situations.
Apps compiled for 4.0 are "frozen" when backgrounded. When they are brought to the front, either from the new task pane or their icon, they are unfrozen and restored to a running state. If the iPhone becomes low on memory it terminates frozen apps from least to most recently used.
So since these apps are already suspended, and must deal with a degree of state change when restored, I'm curious why the OS doesn't/can't page their backing store out to flash memory.
I'm assuming the OS is modern enough that all apps have their own address space so perhaps the hardware doesn't have an MMU capable of the necessary remapping of physical memory into a different address space.
Oh and two nits with Grubers piece. 1) This system is well thought out but it's hardly "state of the art" and 2) on iPhone OS 4.0 backgrounded apps will receive a willTerminate notification before they're completely terminated.