C# 4 and .NET 4

Memory Management Under the Hood ❘ 309
The following code instructs the compiler that you need space in memory to store an integer and a double,
and these memory locations are referred to as nRacingCars and engineSize. The line that declares each
variable indicates the point at which you will start requiring access to this variable. The closing curly brace
of the block in which the variables are declared identifies the point at which both variables go out of scope:
{
}
int nRacingCars = 10;
double engineSize = 3000.0;
// do calculations;
Assuming that you use the stack shown in Figure 13-1, when the variable nRacingCars comes into scope
and is assigned the value 10, the value 10 is placed in locations 799996 through 799999, the 4 bytes just
below the location pointed to by the stack pointer (four bytes because that’s how much memory is needed to
store an int.) To accommodate this, 4 is subtracted from the value of the stack pointer, so it now points
to the location 799996, just after the new first free location (799995).
The next line of code declares the variable engineSize (a double) and initializes it to the value 3000.0. A
double occupies 8 bytes, so the value 3000.0 is placed in locations 799988 through 799995 on the stack,
and the stack pointer is decremented by 8, so that once again, it points to the location just after the next free
location on the stack.
When engineSize goes out of scope, the computer knows that it is no longer needed. Because of the way
variable lifetimes are always nested, you can guarantee that, whatever happened while engineSize was in
scope, the stack pointer is now pointing to the location where engineSize is stored. To remove engineSize
from the stack, the stack pointer is incremented by 8 and it now points to the location immediately after
the end of engineSize. At this point in the code, you are at the closing curly brace, so nRacingCars also
goes out of scope. The stack pointer is incremented by 4. When another variable comes into scope after
engineSize and nRacingCars have been removed from the stack, it overwrites the memory descending
from location 799999, where nRacingCars was stored.
If the compiler hits a line such as int i, j, then the order of variables coming into scope looks
indeterminate. Both variables are declared at the same time and go out of scope at the same time. In this
situation, it does not matter in what order the two variables are removed from memory. The compiler
internally always ensures that the one that was put in memory first is removed last, thus preserving the rule
about no crossover of variable lifetimes.
reference data Types
Although the stack gives very high performance, it is not flexible enough to be used for all variables. The
requirement that the lifetimes of variables must be nested is too restrictive for many purposes. Often, you
need to use a method to allocate memory for storing data and keeping that data available long after that
method has exited. This possibility exists whenever storage space is requested with the new operator — as is
the case for all reference types. That is where the managed heap comes in.
If you have done any C++ coding that required low-level memory management, you are familiar with the
heap. The managed heap is not quite the same as the heap C++ uses; the managed heap works under
the control of the garbage collector and provides significant benefits when compared to traditional heaps.
The managed heap (or heap for short) is just another area of memory from the processor’s available
4GB. The following code demonstrates how the heap works and how memory is allocated for reference
data types:
void DoWork()
{
Customer arabel;
arabel = new Customer();
Customer otherCustomer2 = new EnhancedCustomer();
}
www.it-ebooks.info