I Want My Memory, Apple | Hacker News Reader

I Want My Memory, Apple

gamesfromwithin.com

53 pointsllopis23 comments

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.

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...

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

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).

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.

Google deals with this situation pretty well on Android. You have 16 MB of heap to work with, and you have to deal with their garbage collection.

I agree with the person writing the article. I'd rather have 16 MB of guaranteed RAM available, than maybe 40, or maybe 2. My iPhone app sometimes can't even initialize my tab view controller without crashing depending on the state of the users' iPhone. You can usually get away with using the keyed archiver to page in and out once your app is loaded, but it is typically getting loaded that is the challenge.

This scheme sounds exactly like old state of affairs under the Classic Mac OS back during the 68k era. Macs back then had no MMU, so the OS provided a surrogate "Memory Manager" that abstracted away pointers into handles, which could be marked as purgable, required checking if the memory "moved" due to heap compaction, and so on. As clever as it was at the time (the original Mac fit in 128K, not M, K!), it just proved too limiting and error prone and held down the platform until it was partly jettisoned by OS 8, and fixed for good by OS X.

At some point (I'd say in less than five years) we won't have to worry much about this situation as I envision having 2-4GB of RAM on these devices along with perhaps 100s of GBs of FLASH.

But for now, iPhone applications should implement their own paging system by creating an architecture that allows them to listen to the "applicationDidReceiveMemoryWarning:" message and effectively page parts of itself out of memory and in to flash until needed again.

Are you essentially writing your own MMU? Yes! But that's ok, it's a temporary solution to a temporary problem.

Is an application supposed to be able to run on arbitrarily low memory? If not, I don't see the problem - you run out of memory, end the application with an Out Of Memory error.

Also, I wonder about the memory measurements on the iPhone? I only know from Java that the amount of free memory that the respective method call would return might be much lower than the actual memory available. That is because the garbage collection would sometimes only kick in once the memory would be urgently needed. So before you allocate an object, you might have only 1KB memory left (on paper), after you allocated it, suddenly you have 10MB.

I suspect a similar thing might be going on with the frequent complaints about the memory consumption of Firefox. Just because some system monitor claims that application X is using 100MB of memory doesn't mean application X is REALLY using 100MB of memory. Might be 99% "garbage" that could be collected at any moment.

> Is an application supposed to be able to run on arbitrarily low memory?

Of course. Experience is everything on iPhones (and should be on most devices). If an app crashes, it's bad.

But it doesn't seem to be doable. As the original poster said,you can hardly unload a level in a game if there is insufficient memory. Sorry, but that requirement seems silly to me.

You are right, it doesn't seem to be doable. And that's the point, which is why the author is complaining/writing about it.

Why is a requirement for games not to crash silly? Or do you think apps cannot crash but games can?

It just seems reasonable that an application has a minimum memory requirement. Is it really so bad on the iPhone that memory can be arbitrarily low? What if the iPhone never gives my app more than 1KB memory? I just see no way to make it run reasonably with 1KB.

Also a crash is different from exiting with an error (although still annoying from the user's perspective).

Oh, I see you mean exiting gracefully with an error instead of crashing. That's different, my bad.

But not so different though, because telling a user your game/app can't run anymore because <insert pleasant looking reason here> doesn't help and the user can hardly do anything to help give the app a higher chance to run. Of course they can start Safari, close all the tabs etc, but it is (1) tedious and (2) many users wouldn't know how to do it (3) again destroys the experience.

Also, try to catch the error may not work in practice. It will work sometimes, but there's really no guarantee how much time you have to save the current state, and show a nice error because the app is shutdown.

The irony is that the environment uses reference counting to allow better control of memory yet there is this limitation. Or maybe it had to use reference counting because of this limitation.

Still it's a pretty nice platform to code for, it's just us developers asking for more :)

Wow. Yeah this seems like a staggeringly bad design.

Perhaps now that it's so obvious that the huge majority of apps are games Apple will put more thought into how to make the next iteration of the iPhone into a more capable gaming device.

Reply on news.ycombinator.com