http://blogs.msdn.com/hegenderfer/archive/2007/08/31/slaying-the-virtual-memory-monster.aspx
http://blogs.msdn.com/hegenderfer/archive/2007/10/01/slaying-the-virtual-memory-monster-part-ii.aspx
But to make things clear, sometimes if you have an application loaded and your device acts like its in a low memory situation even though you have plenty of physical RAM free, you may be in a low VM state.
Virtual Memory on Windows Mobile is how much space is available to be used for specific purposes - not how much free RAM you have.
Our applications are designed to use as little VM space as possible, but sometimes by their very nature we have to load Windows Mobile modules - such as RTF support, bluetooth communications, or sound recording as examples - which decrease the amount of VM space available. Usually the biggest culprits to VM space usage are Today plugins and memory hungry SIPs as well as other "system modification utilities" which live in the system space.
As part of the articles above, this quote may help the best:
Where’s the smoking gun?
We already noted that when applications experience VM related failures, there’s not always a smoking gun. The failures can be appear quite random. Let’s talk about some of the most common failures and contributors.
Components that fail to load - The most common failure occurs when an application attempts to load a dependant component – either on startup or through a call to LoadLibrary. There has to be enough space between your heap and the low DLL load position to succeed, so when the DLL load position gets pushed too far down, LoadLibrary will fail. At this point, an application can fail to start or a manual call to LoadLibrary will return an error. The actual affect on an application can vary depending on how it handles this failure.
Memory allocations that fail - When a heap can no longer expand, memory becomes too fragmented, or there is insufficient space for a large contiguous allocation-- memory allocations can begin fail. Few developers write to code to adequately check for memory failures so this very often results in unhandled exceptions for the application (e.g. – crash).
Dynamic failures - It’s pretty easy to take responsibility for problems in your own application—failure to start, exceptions, etc., but it’s even more complex that. VM problems commonly extend into other processes because of the DLL loading and memory rules. How does this happen?
Because every process can contribute to the low DLL load position, this means that the order in which they start can make a big difference. Suppose the low DLL load position has been pushed down to the point where only 10MB of space is left to load more DLLs. What happens then if you have three application—“A”, “B”, and “C” that all load 5MB worth of unique components. If you load “A” and “B”, then “C” fails. If you load “B” and “C”, then “A” would fail.
Part of the challenge today is that VM health is very much a little ecosystem with many contributors. The OEM shares responsible for delivering a device that doesn’t eat up all the VM space before you install the first app. The developer shares responsible for not taking more than their share of resources. The end user shares responsible for all the apps they install. Microsoft shares responsibility for mitigating this problem at a platform level so nobody has think about it. In the not so distant future, we will likely adopt changes in the platform (like we did with CE6) that expand the VM range so that this isn’t an issue anymore. Right now, we have to work with what we have.
