Hacker News Reader

Comment by ankhmoop | Hacker News Reader

I'm not sure the author is sufficiently familiar with the iPhone's memory management. The iPhone will terminate a user process if it consumes all available memory before the OS' low-memory handling has triggered low memory warnings, causing (in this order):

- Running processes (including background processes) expunge caches, non-visible UI, etc.

- Termination of Safari and Mail, which are kept running to improve the user experience.

In reality, one can use up to approximately 40 megabytes of RAM without triggering an application failure, as long as the memory is not allocated and used before the OS has time to free memory by warning/triggering background processes.

While this is more complicated than a guaranteed minimum available amount of RAM, it does permit applications to consume (and rely on) a relatively fixed amount of RAM, and seems a reasonable compromise on a multi-purpose, non-console consumer device.

View on HN

Well the way you use memory in a game is non deterministic, so "OS having time to free memory" is not a good enough answer. Although you're totally right that the IPhone wasn't designed as a console, so this process is probably good enough for most apps.

Even more interresting than the post in itself (wich is very interresting) is the hack proposed by fishermen21 in the comments - http://gamesfromwithin.com/?p=428#comment-1904 - , wich consist roughly of triggering the low memory handling process at the start of the game while reading a video. Nice workaround if you ask me.

Also , maybe someone around here knows, or my question is stupid, but why isn't a virtual memory mechanism implemented into the iphone OS ?

Well the way you use memory in a game is non deterministic, so "OS having time to free memory" is not a good enough answer.

Once the memory is made available to the foremost application, it will not be reclaimed by the operating system; As a game author you do not need to attempt to introduce determinism across all allocations, but instead ensure that initial allocations are not so rapid as to outpace the low-memory handling.

Also , maybe someone around here knows, or my question is stupid, but why isn't a virtual memory mechanism implemented into the iphone OS?

The OS does have a VM, it simply does not have swap space allocated to support paging to disk (flash). Paging would introduce a considerably less enjoyable user experience than forcing applications to account for the available RAM, and significantly decrease flash lifetime.

Just curious, can swap space be enabled on a jailbroken iphone?

Just curious, can swap space be enabled on a jailbroken iphone?

The iPhoneOS doesn't ship with dynamic_pager, which implements user-space allocation and enabling of page files, but in theory, the necessary kernel support should be available.

Enabling paging to a specific file is done via the macx_swapon syscall:

http://fxr.watson.org/fxr/source/bsd/vm/dp_backing_file.c?v=...

dynamic_pager handles allocation of swap files on-demand (requires free ADC account):

http://www.opensource.apple.com/darwinsource/10.0/system_cmd...

In a way, why does it matter if it has paging or not? Either way the total memory available is limited (hard disks don't have infinite storage space).

Yes. Instead of the "less enjoyable" experience of paging, we have the totally appletastic experience of disappearing applications, without warning.

I always assumed they were avoiding the non-trivial impact on lifespan of the internal flash.

They must use some wear leveling algorithm.

Also, this shouldn't really be much of a technical problem going forward since solid state drives clearly have swap space on them.

The iPhone doesn't swap because its flash memory is REALLY CRAPPY. It's terribly slow at even the easiest stuff like streaming reads. Swapping to it would cause epic grinding, so they don't do it (the flash wear that people usually trot out is irrelevant).

While I agree with you, I'd like to know why you think flash wear is irrelevant.

I don't know whether it is a reading issue. It might be a write issue, however. Flash can only allow so many write-cycles, and thrashing is a good way to guarantee flash running out of write-cycles.

In my experience he's spot-on with 15MB - 18MB being the "safe" range. I've seen low-memory warnings past 18MB, and process death shortly thereafter. Relying on the OS to kill off background processes has not been reliable for me, at all.

Also, amusingly, the iPhone will occasionally hang the phone (requiring a reboot.. not just "wait for it to come back") rather than kill your process.

Reply on news.ycombinator.com