#929 – Visualizing How Objects Are Removed from the Managed Heap

Suppose that you create two Dog objects as follows.  (The BestFriend property refers to another dog that is the first dog’s best friend).

            Dog myDog = new Dog("Kirby", 15);
            myDog.BestFriend = new Dog("Jack", 17);

The managed heap now looks as follows:


Now suppose that you then execute the following lines of code:

            Dog yourDog = new Dog("Bowser", 3);
            yourDog = new Dog("Hank", 5);

Now the managed heap looks as follows:
At this point, let’s assume that the Garbage Collector runs, in an effort to reclaim some memory. Notice that the Bowser object is no longer referenced by any reference-typed variable or by another object. Bowser gets marked for collection:


All objects not marked for collection are compacted, moving them to the front (left) of the heap.  After the Garbage Collector runs, the heap is as shown below.  Note that the memory for the Bowser object is reclaimed by the heap.



#927 – Visualizing How Objects Are Created on the Managed Heap

Suppose that you create a couple of new objects and refer to them using referenced-typed variables, as follows:

            Dog myDog = new Dog("Kirby", 15);
            Dog yourDog = new Dog("Bowser", 3);

You now have two variables of type Dog, each referring to an instance of a Dog object.  The Dog objects exist on the managed heap.


Suppose that you now change the yourDog variable to also reference the “Kirby” dog, as follows:

            yourDog = myDog;

The managed heap still contains the two original Dog objects. But notice that the “Bowser” dog is no longer currently referenced by any reference-typed variables.  Bowser is no longer reachable from any of the reference-typed variables, but this Dog object has not yet been destructed, or its memory reclaimed.


#926 – How Memory Is Allocated for Objects on the Managed Heap

When your applications starts up, the Garbage Collector (GC) allocates some virtual memory to use as a managed heap.  It creates a pointer to the next available free space in the managed heap, which defaults to point to the beginning of the (empty) heap.

When you use the new operator to create a new reference-typed object, the Garbage Collector allocates space on the managed heap for your object as follows:

  • It uses the pointer to the next available space on the heap to determine where to store your object
  • It advances the next available free space pointer, based on the size of your object
  • It zeroes out memory for the new object
  • It passes back a pointer to the new object, which is then stored in the reference-typed variable that refers to your object
  • The object’s constructor executes, to initialize data members within the object


#925 – The Managed Heap

The managed heap is an area of the virtual memory available to your process that the Common Language Runtime (CLR) uses for storing instances of reference types (objects) that you create.  The Garbage Collector (GC) is the component in the CLR that is reponsible for allocating memory on the heap for your objects and for releasing that memory when the objects are no longer referenced.


#666 – Looking at .NET Memory Usage Using Performance Counters

As you create new objects in .NET, the garbage collector allocates memory for the objects on the heap.  As memory is allocated, the process consumes some of its available virtual memory.  (In practice, a 32-bit process can allocate at most around 1.5GB of its 2GB maximum).

You can keep track of (roughly) how much memory on the managed heap that your application has allocated by using performance counters.

To track memory usage:

  • Start Performance Monitor


  • Start your application
  • Click the “+” icon to add a counter

  • Expand the .NET CLR Memory section

  • Select the # Total Reserved Bytes counter and select your application

  • Click the Add button and then click OK

You’ll now see a graph indicating total number of bytes of memory that your application has reserved.  The Last field will show you the most recent value.

#200 – Static Data and Constants Are Stored on the Heap

Static data and constants defined in a C# program are stored on the heap.  Since they exist for the lifetime of the application, they do not need to be garbage collected and are therefore stored in a loader heap, rather than the normal Garbage Collected heap.  Specifically, static data is stored on  the high-frequency heap–one of the loader heaps that exists for each AppDomain.


#199 – You Can’t Explicitly Delete Heap-Based Objects

You create a new instance of a reference type by using the new operator and declaring a reference to the new object.  Memory for the object is allocated on the heap and the reference to the object is stored on the stack.

The object itself is able to be destroyed, i.e. its memory freed, when there are no longer any variables that reference it.  This is done automatically by the Garbage Collector (GC) in .NET.

Unlike with C++, you cannot explicitly delete a heap-based object and free its memory.  Only the Garbage Collector can release the memory for the object.  The Garbage Collector will not actually destroy the object unless a) there are no longer any references to the object and b) the CLR invokes the Garbage Collector because it needs memory.

#190 – Memory Management for Heap-Based Objects

In C#, you create an object on the heap when you instantiate an object using the new keyword.

            Person general = new Person("Julius", "Caesar");

We now have a Person object on the heap and a reference to that object–the variable general.

We can also declare a second variable that references the same object.

            Person antonysFriend = general;

Now we have one Person object on the heap and two references to it.

The memory for an object on the heap can be freed when it’s no longer being referenced by any variables.  This can happen when the variables that reference it go out of scope, or when they are set to point to another object.

More precisely, the memory will be reclaimed by the Garbage Collector (GC) in .NET.  When an application needs more memory, the GC is triggered and it releases memory for any dead objects.

#188 – Objects Are on the Heap, References to Objects Are on the Stack

When you instantiate an object, an area of memory on the heap is allocated to store the object’s data.  So we typically say that the object is on the heap.

            Person thatGuy = new Person("Julius", "Caesar");

In the above example, a new instance of the Person class is created and the data for this Person is stored on the heap.

But in creating a new instance of a Person, we also had to declare and instantiate a reference to the Person object that we just created.  That reference is stored on the stack.

In the same way that value types are normally stored on the stack, but can be on the heap if they exist within another object, object references can also be on the heap if they are contained within other objects.

#186 – Value Types on the Heap

Value types are normally allocated on the stack. They can, however, be allocated on the heap–when they are declared within an object.  When an object is instantiated, memory for the entire object, including all of its data, is allocated on the heap.

For example, assume we define a Person class with some properties that are value types (int) and some that are reference types (string).

    public class Person
        string FirstName;
        string LastName;

        int Age;
        int HeightInInches;      // also on heap

        public Person(string firstName, string lastName)
            FirstName = firstName;
            LastName = lastName;

When you create an instance of the Person object,

            Person p = new Person("Zsa Zsa", "Gabor");

the Person object is created on the heap and all of its data members, including the Age and HeightInInches value types, are also on the heap.