How The Windows Mobile 5 Shell Handles Low Memory

[Jon Westfall]

<div class='os_post_top_link'><a href='http://blogs.msdn.com/windowsmobile/archive/2006/08/16/702746.aspx' target='_blank'>http://blogs.msdn.com/windowsmobile.../16/702746.aspx</a><br /><br /></div><i>"I've received a lot of questions over the last while as to how the Windows Mobile shell handles low memory on both Pocket PC and Smartphone and I thought it's about time somebody gave a decent explanation as to how the shell handles this situation. This is mostly an FYI post but hopefully if you're writing an app for Windows Mobile you'll also stop and consider how well your app will behave when confronted by a device running low on resources. To start, low memory is a very important consideration to take into account when dealing with a resource constrained device such as a Pocket PC or Smartphone (or any other embedded device for that matter). Unlike the desktop we don't have a large source of memory to tap and no virtual memory (since we don’t require a device to have secondary storage that we could swap memory out to) so a device can quickly get into a state where most of the available memory is in use."</i><br /><br />Some interesting tidbits of information on memory management on your Pocket PC have been posted on the Windows Mobile Team Blog, with ramifications for building your apps to be more memory sensitive.

[Gerard]

Unlike the desktop we don't have a large source of memory to tap and no virtual memory (since we don’t require a device to have secondary storage that we could swap memory out to) so a device can quickly get into a state where most of the available memory is in use.

I've seen background applications start to close, one after another, with more than 20MB of free RAM on a WM2002 Dell X5. Guess that's not very important... except to the host of folks still relying on that very solid device. Memory leaks were so terrible that I decided to upgrade... which is another story, but anyway, it fixed the leak/close app problem.

With my WM2003SE Toshiba e800, I find that anything less than about 40MB free RAM and the thing becomes unstable. I've been wise in this regard and have installed virtually all of my 75+ applications to either the file store or to SD, and so have at least 95MB of RAM free on every reboot. Still, things get chewed up after hours of use and a lot of apps opened and closed - with Wisbar - and so the old several-soft-resets-per-day routine is still needed. Otherwise I typically see memory drop to under 50MB in a day, even with not a single program running besides startup stuff.

So I wonder, for folks like me, why not offer an optional virtual memory on SD function? It could be a user-controlled toggle in settings, or perhaps the kernel could poll for a card every 30 seconds. Whatever. Pocket Artist has proven with recent versions that using a mounted storage card for swapfiles works just fine from within a memory-hungry application, especially when editing very large images. Why couldn't MS do the same thing Conduits did; namely, make a checkbox allowing use of a card for this function, and an adjustable per-file and total-filesize limit which the more advanced users could set per their needs? If one developer could do this, why not the main OS developer? Or is there some technical roadblock?