Foundations of Programming - Karl Seguin

Chapter 7 - Back to Basics: Memory
Until we look at the interaction between the heap and the stack, the only real way to get in trouble with
the stack is with the StackOverflowException. This means that you've used up all the space
available on the stack. 99.9% of the time, this indicates an endless recursive call (a function which calls
itself ad infinitum). In theory it could be caused by a very, very poorly designed system, though I've
never seen a non-recursive call use up all the space on the stack.
The Heap
Memory allocation on the heap isn't as straightforward as on the stack. Most heap-based memory
allocation occurs whenever we create a new object. The compiler figures out how much memory we'll
need (which isn't that difficult, even for objects with nested references), carves up an appropriate chunk
of memory and returns a pointer to the allocated memory (more on this in moments). The simplest
example is a string, if each character in a string takes up 2 bytes, and we create a new string with the
value of "Hello World", then the CLR will need to allocate 22 bytes (11x2) plus whatever overhead is
needed.
Speaking of strings, you've no doubt heard that string are immutable - that is, once you've declared a
string and assigned it a value, if you modify that string (by changing its value, or concatenating another
string onto it), then a new string is created. This can actually have negative performance implications,
and so the general recommendation is to use a StringBuilder for any significant string manipulation.
The truth though is that any object stored on the heap is immutable with respect to size allocation, and
any changes to the underlying size will require new allocation. The StringBuilder, along with some
collections, partially get around this by using internal buffers. Once the buffer fills up though, the same
reallocation occurs and some type of growth algorithm is used to determined the new size (the simplest
being oldSize * 2). Whenever possible it's a good idea to specify the initial capacity of such objects in
order to avoid this type of reallocation (the constructor for both the StringBuilder and the
ArrayList (amongst many other collections) allow you to specify an initial capacity).
Garbage collecting the heap is a non-trivial task. Unlike the stack where the last scope can simply be
popped off, objects in the heap aren't local to a given scope. Instead, most are deeply nested references
of other referenced objects. In languages such as C, whenever a programmer causes memory to be
allocated on the heap, he or she must also make sure to remove it from the heap when he's finished
with it. In managed languages, the runtime takes care of cleaning up resources (.NET uses a
Generational Garbage Collector which is briefly described on Wikipedia).
There are a lot of nasty issues that can sting developers while working with the heap. Memory leaks
aren't only possible but very common, memory fragmentation can cause all types of havoc, and various
performance issues can arise due to strange allocation behavior or interaction with unmanaged code
(which.NET does a lot under the covers).
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
54