Foundations of Programming - Karl Seguin

Chapter 7 - Back to Basics: Memory
Back to Basics: Memory
NOT 'GETTING' ALGEBRA IS NOT ACCEPTABLE FOR A MATHEMATICIAN, AS NOT
'GETTING' POINTERS IS NOT ACCEPTABLE FOR PROGRAMMERS. TOO FUNDAMENTAL.
- WARD CUNNINGHAM
T
ry as they might, modern programming language can't fully abstract fundamental aspects of
computer systems. This is made evident by the various exceptions thrown by high level
languages. For example, it's safe to assume that you've likely faced the following .NET exceptions:
NullReferneceException, OutOfMemoryException, StackOverflowException and
ThreadAbortException. As important as it is for developers to embrace various high level patterns
and techniques, it's equally important to understand the ecosystem in which your program runs.
Looking past the layers provided by the C# (or VB.NET) compiler, the CLR and the operating system, we
find memory. All programs make extensive use of system memory and interact with it in marvelous
ways, it's difficult to be a good programmer without understanding this fundamental interaction.
Much of the confusion about memory stems from the fact that C# and VB.NET are managed languages
and that the CLR provides automatic garbage collection. This has caused many developers to
erroneously assume that they need not worry about memory.
Memory Allocation
In .NET, as with most languages, every variable you define is either stored on the stack or in the heap.
These are two separate spaces allocated in system memory which serve a distinct, yet complimentary
purpose. What goes where is predetermined: value types go on the stack, while all reference types go
on the heap. In other words, all the system types, such as char, int, long, byte, enum and any
structures (either defined in .NET or defined by you) go on the stack. The only exception to this rule are
value types belonging to reference types - for example the Id property of a User class goes on the heap
along with the instance of the User class itself.
The Stack
Although we're used to magical garbage collection, values on the stack are automatically managed even
in a garbage collectionless world (such as C). That's because whenever you enter a new scope (such as a
method or an if statement) values are pushed onto the stack
and when you exit the stack the values are popped off. This is
why a stack is synonymous with a LIFO - last-in first-out. You
can think of it this way: whenever you create a new scope,
say a method, a marker is placed on the stack and values are
added to it as needed. When you leave that scope, all values
are popped off up to and including the method marker. This
works with any level of nesting.
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
53
7
If you've ever wondered why a
variable defined in a for loop or if
statement wasn't available outside
that scope, it's because the stack
has unwound itself and the value is
lost.