WinDBG demo : Garbage collector (GC) effect on generational heaps

This blog provides 30+ Hands-on labs to learn .NET debugging using WinDBG.
Please visit the Tutorial Index page to view all exercises.

.NET CLR concept

We know that when Garbage collector (GC) arrives to a generational heap,

1.   The strongly referenced objects  will be moved to Higher heap region

2.   Unreferenced objects on that heap will be collected by GC

Demo Walk through

This hands-on demo has two parts. User will analyze two application dumps of the same application. 

   1.  First dump has taken Before a Garbage collection appearing on the application.
   2.  Second dump is the application state after the GC occurrence

By Comparing both the dumps, we will prove the theory concepts stated above. On this course, two new WinDBG commands will also be learned.

a.    !gcwhere  => Command prints which Generational heap the object stays.

b.    !gcroot   => Command show the referential chain on the object

Suggestion : We have prepared a short demo walk through video explaining concepts and steps. We insist  the users to watch it before they do the hands-on to get the clear picture.
YouTube video available  Here

Demo Scenario

While standing in front  of his  house , a  kid saw two  footballs (Red, blue) on the street. He picked the Red one. Later , the other ball is swept away by the street sweeper.

Here the Kid has a strong hold on the Red ball. So it is not collected by the sweeper.

Let's mimic this programmatically . A code block is given below. Two football objects created and the red ball is accessed by the Kid object.

Step-by-step instruction(Before GC arrival)

1.  Download and unzip the dump(GCBehavior_BeforeGC.dmp) file from this Location

2. Start WinDBG (x86 version)

3. Open File Menu => Open Crash dump

4. Select the dump file "GCBehavior_BeforeGC.dmp" . Apply OK

5. Load SOS dll in the command prompt. Apply .loadby sos.dll clr

     (image given below)

6 .  The application heap has two football objects. lets print those objects from memory.  for that,          a) Apply command !dumpheap -type Football
         b) it will print two football objects . result image given below
        

7. Now we need to know in which generational heaps these objects reside. for that copy the address of the first object and apply a command  as below,

!gcwhere {copied object address}

Result image given below. observe the object is at gen 0 heap region.

8. do the same (step 7) for second object by copying its address. We can see it is also staying in gen 0 heap. 9. So we understood both objects are at generational 0 heap. Out of these two, one object is Red and other is Blue in color and the Red football is rooted(in hold) by Kid.
So  in order to understand which one is rooted , we can use a command !gcroot.
             a) copy the first object, Apply a command !gcroot {address}
             b) it will print the reference chain on the object. Result is given below.
             c) observe the red arrow ( Kid object is referring football object)

 

10. So we saw the first object is rooted with Kid, it must be the red football. lets also see the next football with !gcroot command.
a)  Apply !gcroot {second address} . result image given below
b)  No roots !. so it is the blue football.

Summary 

We analyzed our first demo. We understood that both objects are staying at Gen 0 heap region and one object is strongly referenced and the other football object is unreferenced .

Now consider a GC happened on the application. What would happen to these objects?  Lets analyze the second dump which had collected after the GC occurrence on the application.

Second dump : Step-by-step instructions(After the GC arrival)

1.  Download and unzip the dump(GCBehavior_FirstGCHappend.dmp) file from this Location
2. Start  another instance of WinDBG (x86 version) or close the first demo and reopen WinDBG
3. Open File Menu => Open Crash dump
4. Select the dump file "GCBahavior_FirstGCHappend.dmp" . Apply OK
5. Load SOS dll in the command prompt. Apply .loadby sos.dll clr
6.  lets print the football objects from memory.  for that,

         a) Apply command !dumpheap -type Football
         b) result printed. Image given below.

 
( Before going to next step, observe that now only one football object available in the heap.
  This means that , the GC had collected the un-referred object (blue ball) . So the first concept has proved : GC collects un-refferred objects from the heap.

7. Now we need to know where the existing object stay in the heap after the GC operation. (in the first demo ,both objects were at Gen 0 heap)

a. Apply command !gcwhere {address of object}
b. Now the football object is available at Gen 1

So it is proved that GC transfers the referred objects from a generation to next.

Exercise for the user

Applied one more GC on the application and then a dump has taken. user can analyze the third
 dump (GCBehavior_SecondGCHappend.dmp).  The file can be downloaded from Here

The steps are exactly same as second demo.  The only difference is , user can see the football object moved to Gen 2 heap region (Since GC happened two times on the app, the object in Gen 1 area moved to gen 2 heap) Figure given below

Watch the demo

Watch the step-by-step demo video showing how heap objects respond to the Garbage collection operation.