In the previous post, I gave a brief overview of what stacks do. In this post, I will pick up from where I left off about the interesting world of heaps. As you will see, heaps are not independent of stacks, so if you have glanced over my earlier post, it is a good idea to do so.

Heaps, like I mentioned in my previous post, deal primarily with reference types, and one popular reference type that you may already be familiar with is a class. To best explain how the heap works, let me first show you an example:

class Simpsons

{

public string name;

public int age;

}

 

public void People()

{

Simpsons bart = new Simpsons();

bart.name = "Bart";

bart.age = 10;

}

The above code has a class called Simpsons, and the Simpsons class has two public fields called name and age. You access the Simpsons class via your People method, and inside your People method, you both create a bart object of type Simspons and initializie the bart object's name and age fields.

Now that you an idea of what the code does, let's take a look at how both our stack and heap look like at the end of running the People method:

Your stack, like before, contains the People method call, and it includes an entry for bart. Notice that bart isn't pointing to a value, but instead it is referencing the Simpsons object on the heap. The reason is that Simpsons is a class aka a reference type, and like I mentioned before, reference types usually belong on the heap.

Garbage Collection
After your People method has finished running, your stack would once again be empty since it only contains information on code that is or will be running. With nothing left to run, our stack will be empty. The heap, on the other hand, can still contain data:

In such a situation, you will have something called a Garbage Collector that goes through and clears unreferenced/unused data from the heap. For example, the Simpsons class above would be removed because it is no longer being used, and you will end up with an empty stack and heap. I should clarify that in most scenarios, when your application is more complicated than the example presented in this post, you may have some data from other methods taking up space in both your stack and heap.

There are numerous approaches garbage collectors take when attempting to optimize free space, and that depends on your language and runtime environment. Visual Basic 6 and earlier used a reference counting approach where you count the number of references each object on the heap has pointing to it, but (as far as I know) .NET uses a reference tracing approach. Most algorithms that attempt reference tracing build a tree of all objects based on entry points in your application called roots. Any objects that don't make it onto the tree are assumed to be wasted space, so they are quickly cleaned up.

The actual GC implementation in the .NET VM's may go several steps beyond what I explained, and there are various topics that I will not cover in this article such as dealing with fragmentation or how objects get prioritized for removal. If you are curious to learn more about these topics, the following course notes may come in handy.

Using the = Operator with Reference Types
With value types, when you set one variable equal to another variable, the actual data gets copied. For example, take a look at the following code:

static void Main()

{

int x = 10;

int y = x;

 

x = 5;

 

// x = 5

// y = 10

}

I set the y variable equal to x, and I then change the value of x to be 5. In the end, the values stored by x is 5 and the value stored by y is 10. This is just what we want! With reference types, though, setting one variable equal to another variable only transfers the reference to the same object on the heap.

Let's look at a demo of what I am referring to:

class Simpsons

{

public string name;

public int age;

}

 

public void People()

{

Simpsons bart = new Simpsons();

Simpsons bort = bart;

 

bart.name = "Bart";

bart.age = 11;

 

bort.name = "Bort";

bort.age = 22;

}

In the above example, I create two objects called bort and bart. The thing to note is that the bort object is set equal to the bart object, and I then proceed to populate the fields in the bort and bart objects. When I Console.WriteLine bart's name as in bart.name, what is the output you get? What should be the output you want?

The output for bart.name will be Bort. The output you would have wanted would have been Bart. The reason for this goes back to the difference between value and reference types that I briefly mentioned earlier. Let's look at both the stack and heap for the above example:

Do you see the issue? Both the bort and bart objects are referencing the same thing! By setting bort = bart, what I essentially did was set the bort reference equal to the bart reference. That brings us full-circle back to a simple fact of programming in .NET and most other languages: reference types store references and value types store values!

Just a final word before we wrap up. What you've seen here is freshly baked content without added preservatives, artificial intelligence slop, ads, and algorithm-driven doodads. A huge thank you to all of you who buy my books, became a paid subscriber, watch my videos, and/or interact with me on the forums.

Your support keeps this site going! 😇

Need help?

Ask on the forums!

• Previous Article
• Next Article