2.2 Automatic Memory Management

2.2 Automatic Memory Management

The Common Language Runtime does more for your C# and .NET managed executable than just JIT compile them. The CLR offers automatic thread management, security management, and perhaps most importantly, memory management.

Memory management is an unavoidable part of software development. Commonly memory management, to one degree or another, is implemented by the application. It is its sheer commonality combined with its potential complexity, however, that make memory management better suited as a system service.

Here are some simple things that can go wrong in software.

· Your code can reference a data block that has not been initialized. This can cause instability and cause erratic behavior in your software.

· Software may fail to free up a memory block after it is finished with the data. Memory leaks can cause an application or an entire system to fail.

· Software may reference a memory block after it has been freed up.

There may be other memory-management related bugs, but the great majority will fall under one of these main categories.

Developers are increasingly taxed with complex requirements, and the mundane task of managing the memory for objects and data types can be tedious. Furthermore, when executing component code from an un-trusted source (perhaps across the internet) in your same process with your main application code you want to be absolutely certain that the un-trusted code cannot obtain access to the memory for your data. These things create the necessity for automatic memory management for managed code.

All programs running under the .NET Framework or Common Language Runtime allocate memory from a managed heap. The managed heap is maintained by the CLR. It is used for all memory resources, including the space required to create instances of objects, as well as the memory required for data buffers, strings, collections, stacks and caches.

The managed heap knows when a block of data is referenced by your application (or by another object in the heap), in which case that object will be left alone. But as soon as a block of memory becomes an unreferenced item, it is subject to garbage collection. Garbage collection is an automatic part of the processing of the managed heap, and happens as needed.

Your code will never explicitly clean-up, delete, or free a block of memory, so therefore it is impossible to leak memory. Memory is considered garbage when it is no longer referenced by your code, so therefore it is impossible for your code to reference a block of memory that has already been freed or garbage collected. Finally, because the managed heap is a pointer-less environment (at least from your managed code’s point of view), it is possible for the code verifier to make it impossible for managed code to read a block of memory that has not been written to first.

The managed heap makes all three of the major memory management bugs an impossibility.