Saturday, May 31, 2008

Memory management on Windows Mobile <= 6.1

Recently in the communities a question was asked: "Why should I bother finalizing my objects, shouldn't I let the GC do it for me?". It's true we have the wonderful Garbage Collector (GC) in managed code and luckily it is supported on the Compact Framework. Here's a statement: *never* rely on the GC, in fact don't call it, ever. OK, there may be some scenarios you might want to call it in extreme cases, but for the most part, please don't, think of your users ;) instead write better code!
This article is was written to show an example of how Windows Mobile 6.1 and earlier handles memory management and the various events you can hook into to develop more robust applications.

I'm running the following code on a HTC P3300 with 64meg RAM not much by todays standards but the device is 18 months old now so in mobility terms ready for the scrap heap. I happen to have just 22meg free after running this application:




You'll see from the screenshot above I have written out the physical free memory available to applications on my device. Although there is no managed function to achieve this even in CF 3.5, it can be done by P/Invoking function GlobalMemoryStatus. The code to do this is fairly simple ie:
public struct MemoryStatus
{
internal uint dwLength;
public int MemoryLoad;
public int TotalPhysical;
public int AvailablePhysical;
public int TotalPageFile;
public int AvailablePageFile;
public int TotalVirtual;
public int AvailableVirtual;
}

//Declaration.
[DllImport("coredll", SetLastError = false)]
internal static extern void GlobalMemoryStatus(out MemoryStatus status);

This app has been developed using CF 3.5 and VS 2008 Team Suite. I have created a simple form with one button labled "Eat memory". The code looks like the following:
 public partial class Form1 : Form
{
public struct MemoryStatus
{
internal uint dwLength;
public int MemoryLoad;
public int TotalPhysical;
public int AvailablePhysical;
public int TotalPageFile;
public int AvailablePageFile;
public int TotalVirtual;
public int AvailableVirtual;
}

[DllImport("coredll", SetLastError = false)]
internal static extern void GlobalMemoryStatus(out MemoryStatus status);

private List bytelist = new List();

public Form1()
{
InitializeComponent();
}

private void Form1_Closed(object sender, EventArgs e)
{
System.Diagnostics.Debug.WriteLine(string.Format("{0} : Form1_Closed called",
DateTime.Now.ToLongTimeString()));
}

private void CurrentDomain_UnhandledException(object sender,
UnhandledExceptionEventArgs e)
{
System.Diagnostics.Debug.WriteLine(string.Format("{0} :
CurrentDomain_UnhandledException called",
DateTime.Now.ToLongTimeString()));
}

private void MobileDevice_Hibernate(object sender, EventArgs e)
{
System.Diagnostics.Debug.WriteLine(string.Format("{0} : MobileDevice_Hibernate
called",
DateTime.Now.ToLongTimeString()));
Clear();
}

private void Clear()
{
if (bytelist != null)
{
System.Diagnostics.Debug.WriteLine(string.Format("{0} : Clear called
(cleanup unused memory objects)",
DateTime.Now.ToLongTimeString()));
bytelist.Clear();
}
}

private void eatMemory_Click(object sender, EventArgs e)
{
MemoryStatus status = GetMemoryStatus();

for (int i = 0; i < 21; i++)
{
bytelist.Add(new MyClass());
}

status = GetMemoryStatus();
memoryAfter.Text = "Memory after: " +
status.AvailablePhysical.ToString();

}

private MemoryStatus GetMemoryStatus()
{
MemoryStatus status = new MemoryStatus();
GlobalMemoryStatus(out status);
return status;
}

private void resetTest_Click(object sender, EventArgs e)
{
Clear();
MemoryStatus status = GetMemoryStatus();
memoryBefore.Text = "Memory before: " +
status.AvailablePhysical.ToString();
memoryAfter.Text = "Memory after: -";
}

private void Form1_Load(object sender, EventArgs e)
{
Microsoft.WindowsCE.Forms.MobileDevice.Hibernate += new
EventHandler(MobileDevice_Hibernate);
AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
Closed += new EventHandler(Form1_Closed);
Closing += new CancelEventHandler(Form1_Closing);
resetTest_Click(this, EventArgs.Empty);
}

private void Form1_Closing(object sender, CancelEventArgs e)
{
System.Diagnostics.Debug.WriteLine(string.Format("{0} : Form1_Closing called",
DateTime.Now.ToLongTimeString()));
}
}

public class MyClass
{
private byte[] mybyte = new byte[1000000];
}
The code is very simple. We have created a class named MyClass which allocates a 1mb byte array. We simply have hardcoded a loop to iterate through 21 times whwn the "Eat memory" button is pressed so we get less than 2mb free RAM. You'll probebly thinking, why didn't I just calculate the amount of free RAM before the test and allocate a buffer slightly smaller than the free physical memory limit. This didn't seem to work because of the way the OS allocates and frees memory. I found simply hardcoding it worked better for this test. I needed to get between 1 and 2 free mb which was actually harder than it seems! We create a generic array list to hold references to each of the 1mb MyClass objects. We store this array list object at class level so the GC won't try to clean it up when times get tough.

Just to be clear, usally you wouldn't handle all these events under the UI layer, it would be abstracted out usally to the DeviceManagement level (business). We have added hooks to the following events:

Microsoft.WindowsCE.Forms.MobileDevice.Hibernate
System.Windows.Form.Closing
System.Windows.Form.Closed
System.AppDomain.CurrentDomain.UnhandledException

The OS will send the WM_HIBERNATE message to all applications when the amount of free RAM falls below its minimum limit and will stop when it has enough reserve resources to do whatever it needs to do. In .NET, the event that traps the WM_HIBERNATE message is Microsoft.WindowsCE.Forms.MobileDevice.Hibernate. The objective of handling this message is to give your app a chance to redeem itself and clean up any unused memory it may be hogging. Note: You have to explicitly add the Microsoft.WindowsCE.Forms.dll assembly to your project, VS doesn't do this for free.

WM_CLOSE will be sent if the WM_HIBERNATE made little difference sometime after WM_HIBERNATE was sent (I'll show an example of this architecture later). System.Windows.Form.Closing event will be called when the OS sends the WM_CLOSE message if the app is hogging memory which the OS needs then finally, System.Windows.Form.Closed will be called which terminates the app.

System.AppDomain.CurrentDomain.UnhandledException this traps unhandled exceptions in the current app domain which allow us to clean up our code and write a file somewhere, so next time our app loads it sends debugging information to the back office which can be used to fix the error in future builds. I'll show an example of this later.

Remember we said my HTC 3300 device had 22 meg of free RAM before pressing the "Eat memory" button in the above code, well after pressing the "Eat memory" button we now have 1.6 meg of free RAM. Not alot at all, navigating the device is very very slow as one would imagine.


Free RAM after running "Eat memory".

So what should happen now? well, the OS should firstly send the WM_HIBERBATE message to each application running in hand until it has enough memory as the device is in an unstable state and needs more memory to handle things like phone calls, radio etc. I think this freshhold is somewhere above 2mb.

Guess what, WM_HIBERNATE is called which should give our application a chance to cleanup that horrible 21 meg array that we're not using. But in the code documented earlier, did you notice in the MobileDevice_Hibernate event, we commented out the call to the Clear() method.
private void MobileDevice_Hibernate(object sender, EventArgs e)
{
System.Diagnostics.Debug.WriteLine(string.Format("{0} : MobileDevice_Hibernate
called",
DateTime.Now.ToLongTimeString()));
//Clear();
}
This of course was deliberate to demonstrate what happens in this scenario which emulates what could happen if you do not code for these scenarios. Well as I mentioned earlier the WM_CLOSE will be sent soon after if there are still not sufficient free resources after initiating a WM_HIBERNATE message. We are using the Dianostics.Debug.WriteLine() method to let us know what is happening.

So as we haven't cleaned anything up, we should expect a WM_CLOSE pretty soon.....guess what, we do. See the following output window:


Output when memory limit hits the threshold and WM_HIBERNATE and WM_CLOSE messages are received.

You can see how long it takes for the WM_CLOSE event to occur after the WM_HIBERNATE because we have timestamped the events, here it is 14 seconds. One thing to note after the WM_HIBERNATE message is received a full implicit GC.Collect() is executed. But because we didn't in the above code example clear the array list which is holding onto 21 meg of valuable resource, the GC did little good, so a WM_CLOSE message was sent. Often if the WM_CLOSE has little effect then the OS will kill the app!

So what happens if we uncomment the Clear() method in the MobileDevice_Hibernate event? well lets see.....


Output when memory limit hits the threshold and WM_HIBERNATE message is received

Now this is a different story from before. We can clearly see the hibernate message has been received from the output above and this was received because we reached less then 2meg of free physical memory on the device after pressing the "Eat memory" button. We then called the Clear() method which clears the array of 21 meg MyClass objects. Remember the GC would then be called as soon as the WM_HIBERNATE message returns. So lets examine the available memory in control panel:


Memory applet after cleaning up unused objects.

Wow, this is amazing, now look, we are back to where we were in terms of free physical memory before clicking the dreadful badly written "Eat memory" button!

This demonstrates the fact that you should never rely on the GC even though we are coding in a memory managed evironment today. Native development principles in terms of memory management still apply today as they ever did. This also backs up the fact that sometimes the GC won't help you ;)

There are scenarios where you could blow the free amount of RAM in almost one hit. In these senarios, the OS simply doesn't have a chance to try and get the app to behave itself as clearlyit's not and there is no time to try and get it to behave itself . Usually in these cases an OutOfMemory exception is generated. Here we can then trap these exceptions by registering the AppDomain.CurrentDomain.UnhandledException message. Of course there is no way to rescue your app in these situations, so the only thing you can really do is close everything down safely and write a debug file and transmit it to your back office for debugging information purposes. It is also nice to applogize to the end user once the app loads again and maybe display some info as to what happened. This can be done by simply writing a log file somewhere than the app checks on load.

10 comments:

Anonymous said...

Hi,
I do have an outofmemoryexception in my app. Since the device has 256MB I have no idea why this happens. During execution there are only about 20MB used. So I wrote a little app pretty much like yours. Eating 1MB each loop I get an exception when i==25- but there ist still over 100MB available. Any idea whats going on here?

Simon Hart said...

What device are you running on? there is as max limit on pre WM 6.1 of a 32 meg per process.

--
Simon.

Anonymous said...

Thank you for a very good post.

Jason said...

Hi there,

I was wondering if you are able to suggest how the thresholds can be changed. My 64MB device seems to call WM_HIBERNATE at 10MB free which can be quite painful when listening to music + browsing for instance - WMP will always get killed. Any suggestions would be great.

Cheers,
Jason

Anonymous said...

Hi Simon

I have a WM6.1 application .netcf vb which needs to incorporate memory management as you have described. Is your example code available in vb? I am based in London and wonder if you could review my entire code (for a fee ofcourse) to improve its performance. The app freezes up after a while presumably due to low memory.

ayo owoade
owoade@btinternet.com

Jörn said...

To anyone interested, to force a WM_HINERNATE message being sent from C# just use this:

[DllImport("coredll.dll")]
private static extern int SendMessage(IntPtr hWnd, uint msg, int wParam, int lParam);

public const uint HWND_BROADCAST = 0xffff;
public const uint WM_HIBERNATE = 0x03FF

SendMessage((IntPtr)HWND_BROADCAST, WM_HIBERNATE, 0, 0);

That's all. No need to allocate memory or anything else...
A better formatted version is online here on my blog:
http://blog.koerner.in/index.php?/archives/6-Sending-the-WM_HIBERNATE-message....html

Simon Hart said...

@Jason:

Sorry for the major late reply. I don't think the WM_HIBERNATE message threshold can be changed. It sound slike you have hit the threshold of 32-meg per process. Use the Remote Performance Monitor tool to check what your application is doing.

Simon.

Simon Hart said...

@Jorn:

Thanks for this code snipet. I know about this message, but the article was about getting the developer to understand what WM_HIBERNATE actually means and how to handle it. So a good way to get an understanding to the reader is to show a real example.

Cheers
Simon.

PDAddy said...

Hello,

So i have 533Mhz processor with 128MB RAM on my ACER F900 PDA. However the programs run painfully slow and it freezes too quickly (even though i just have active sync 536kb in the background)

can I increase the RAM or make things run faster/without crashing...I thought 128mb was good enough for at least browsing and music and GPS....

thanks a bunch!

Unknown said...

Hi is there a way to programatically retrieve the amount of memory taken in by a process on Window Mobile. This is an easy task a normal Window computer but I've struggle all weekend to get a running process's memory comsuption count.