Memory management for .Net applications can seem mysterious. This article explains some of the inner workings of memory management in the .NET CLR and Windows operating system to shed some light a topic that confuses a lot of .Net developers.
This article was written for Visual Basic developers who use Microsoft.NET versions 1.0 and 1.1.
While serious memory issues may warrant the use of a commercial .NET memory profiler, many memory issues can be resolved by just learning more about how memory management works and using the free .NET memory profiling tools available to you in Visual Studio and from third-parties.
Common Questions About Memory
What do these questions and statements have in common?
Why does my Hello World! application use 12 MB of memory?
I don’t think the garbage collector in .Net is doing its job. My application keeps using more memory.
My .Net applications use a lot more memory than my VB6 applications.
I have a memory leak, what should I do?
The answer is: More often than not, the questions and statements come from confusion about how the Common Language Runtime (CLR) and the Windows Operating System (OS) manage memory.
Generous Memory Allocation
Unless memory is in short supply, the OS allocates each running application more than the minimum physical memory required for it to run. The OS commonly give applications like Word and Excel more than a ‘just get by’ memory allocation. It is just as generous with the memory it allocastes to our .Net applications.
Windows OS - If physical memory is not in short supply, the OS will give applications more or less all the RAM memory they ask for. When demand for memory exceeds supply, the OS will take back physical RAM from an application that is not using it to give it to an application that needs it.
CLR - If memory is not in short supply, .NET applications may use more memory than they need. A good example: when a .Net application is loaded into memory, assemblies are loaded in what is a fairly expensive but transient operation. After the assemblies are loaded and if memory is not in short supply, the leftover unused memory from loading the assemblies is left behind rather than being reclaimed.
Working Set, Minimum Working Set, and Maximum Working Set
You many find it helpful to know a little more about memory management on your Windows computer. A good way to start is to learn a little about memory internals, specifically memory working set, minimum working set, and maximum working set. For this article’s purposes think ‘application’ when you see the word ‘process’ in the definitions below.
Working Set
The set of memory pages that is resident in physical RAM for a given process while it has one or more running threads.
The size of each process's working set is bounded by a minimum working set (minimum number of memory pages that the Memory Manager guarantees to be resident in RAM while the process has one running thread) and by a maximum working set (a maximum number of memory pages of RAM that may be allocated to the process).
However, the NT kernel does not necessarily constrain a process's working set to its maximum working set boundry if many free pages are available. Why? One important reason is that performance wise it is better to over allocate memory to each process if memory is plentiful and only take it away if memory becomes scarce.
More simply you can think of the working set as the number of bytes of physical RAM being used by a process at a particular point in time. This varies according to the needs of a particular process and the needs of other processes running on the same computer. If free memory is plentiful the number of bytes of RAM allocated to a process will be closer to its Maximum Working Set size. If memory is in short supply, this number will be closer to its Minimum Working Set size.
Minimum Working Set
The virtual memory manager attempts to keep at least this much memory resident in the process whenever the process is active.
Maximum Working Set
The virtual memory manager attempts to keep no more than this much memory resident in the process whenever the process is active and memory is in short supply.
.Net Urban Legend
It is possible to reduce the working set size of a .Net Windows Forms application by minimizing and then maximizing the application immediately after it loads. Windows OS trims the working set of applications when they are minimized. The memory that was briefly used while loading all those assemblies mentioned earlier is trimmed by the process of minimizing and maximizing the application.
You can demonstrate this behavior to yourself by creating and running a Windows Forms application with just Form1 and no added code.
1. Create and run the simple application.
2. Open the Windows Task Manager and then its Processes Tab. You will see the Task Manager shows your application’s memory usage at approx. 12.5 MB.
3. Now minimize your application and then maximize it. Check the Task Manager again. You will see the Task Manager now shows your application’s memory usage at approx. 1.5 MB. The memory that was used to load assemblies when your application was launched was reclaimed by memory management when you minimized the application.
Did you improve memory management or application performance by minimizing and maximizing your application? No.
You can find some .Net Windows programmers who add code to minimize and then maximize their programs thinking that they are optimizing memory. As these programmers have shared this technique with others a sort of .Net Urban Legend has been born – a programming practice based on fiction not fact.
This practice is unnecessary because when OS needs the unused memory left behind when the assemblies were loaded it will reclaim it automatically. In fact, decreasing the size of your application’s working set when memory is plentiful may decrease performance.
Memory Management Demonstration
One of the best ways to watch the Widows OS and the CLR manage memory is to conduct a memory stress test.
Below is an excerpt from a post I made to the Microsoft .Net Framework newsgroup in the fall of 2002. Try the "experiment" I outline in this excerpt for yourself to witness the some of the memory management dynamics of the OS and CLR. Here is the excerpt.
"I have not had any memory issues with the Win Forms applications I have developed. But I have seen many forum postings expressing concern about how much memory .NET applications consume and I became more and more curious why so many posts like this were showing up in the forums. The posts I have seen often express concern that even a simple Hello World application may use approx. 12 MB of memory.
I asked a few folks at Microsoft about this. I was told that if RAM memory is plentiful, an application may grab a very generous chunk of it. An application will not be so 'greedy' (my own words) if available memory is scarce.
I performed an experiment. I created the Hello World Windows Forms application, and then opened 51 instances of it. I used the Windows Task Manager to monitor memory usage. On my two year old Dell Latitude, with 512 MB of memory, running XP - here is what happened:
The first instance of the Hello World application took 12.5 MB of memory. Until I got to around 41 instances, each instance I opened took another 12.5 MB of memory. Then, with memory getting each instance I opened took less and less memory.
The last five instances of Hello World I opened took 1.7 MB of memory.
I right clicked on the group of 51 Hello World applications showing the Widows taskbar and chose Close Group to force all instances to close down. I watched the Task Bar memory manager as each instance closed in turn. Memory was rapidly returned to the system. In 15 seconds all instances were closed and available memory was back to where it was when I started the experiment."
from: http://getdotnetco.web119.discountasp.net/GdncStore/free/Articles/The%20Memory%20Mystery.htm
