Speaking of which... : GC

Why doesn’t the GC kick in when the worker process is inactive?

JohanS — Tue, 13 May 2008 16:39:48 GMT

I got the following question in my Getting started with windbg – post and I thought it might be worth posting the replies in a separate article:

Hi Johan,

about those threads with an ID of XXXX, should they go away after certain amount of idle time like 2 minutes? I am trouble shooting an application while the application should sit idle (because of no stimulation), however it is still using quite some CPU time and and threadpool threads, where it should not. So I created an adplus dump when it is sitting idle, and I found that there are many threads with ID XXXX, and I created a dump file again after 15 minutes, again, it still have the exact same XXXX threads. All those threads are completion port threads, and I wonder why they did not get recycled?

Also, when doing a '~*e !clrstack', most of the worker threads and completion port threads are showing "Failed to start stack walk: 80004005". Is there a way to show the stack for those threads, because those are the threads I am interested in.

Thank you!

The GC will be triggered when you’re allocating memory. If your application is inactive, then so is the Garbage Collector. Even if you’re making a few, random allocations they still may not be enough to trigger a GC, so this is not at all unexpected.

The “Failed to start stack walk: 80004005”-error is displayed when the thread did contain a managed stack, but no longer does.

/ Johan

The KB article every one should know about

JohanS — Wed, 23 May 2007 18:23:46 GMT

Have you read http://support.microsoft.com/?kbid=307340? If not, I suggest you do so. If you need convincing or simply want to know why this problem occurs I suggest you keep reading.

The problem described in the article above can cause your application to spike in CPU time, Memory usage or both. This will lead to your application hanging or possibly even crashing. The cause of the problem is one of the most basic operations, and is something that we do very frequently.

The problem

The problem in a nutshell is that string concatenation is bad. I don't mean bad as in "You shouldn't eat that extra piece of chocolate". I mean it as in "You really shouldn't put your head in wet concrete". If you've been reading my previous post on memory management you might be able to figure out why string concatenation could be such a potential hazard. Consider the following scenario:

You're getting ready to go grocery shopping. You take a sheet of paper and a pen and begin writing down what you need to buy. The first item that crosses your mind is milk, so you write it down. Now you remember that you're out of bread as well, so you throw away the first sheet of paper, pick out a new one and write down milk and bread. You then throw away this paper too and write down milk, bread and apples on a third piece of paper. You throw away the third piece of paper and repeat until finally the list is done. If you have 20 items on your list you now have 19 discarded papers lying on the floor waiting for the "garbage collector".

This is exactly how regular string concatenation works in .NET. Every time you concatenate a string the framework needs to allocate a new memory segment, large enough to hold the result of the concatenation and store the string in this new segment. The old segment is flagged as ready for garbage collection and as we all know garbage collection costs CPU and pending garbage collection costs memory.

A real example

So if you thought that 19 sheets of paper were a waste consider the following piece of code:

private String buildTable()
{
   String sReturn;
   int i, j;
   sReturn = "<table>"
   for (i = 0; i < 35; i++) // Rows
   {
      sReturn += "<tr>"
      for (j = 0; j < 15; j++) // Columns
      {
         sReturn += "<td>"
         sReturn += i.ToString() + " : " + j.ToString();
         sReturn += "</td>"
      }
      sReturn += "</tr>"
   }
   sReturn += "</table>"
   return sReturn;
}

All in all we have 2697 concatenations which means we have 2696 unnecessary allocations. The allocations will be gradually bigger and bigger, so the last ones will be almost as big as the final table. Needless to say this will consume a lot of unnecessary memory. Also, if this table was built for a "real" application it would probably contain a lot more data for each cell, not to mention custom styles and classes. Imagine what would happen when the string goes past the magic 85000 bytes barrier that defines what goes on the large object heap and what doesn't. In a larger scale this would have a severe impact on performance.

This is a really weird behavior, how can it be?!

It's not that odd really. If we extend the grocery shopping analogy a little we can see why there's a logical reason for this: You know that you want to write something down. You have a limited amount of paper, so what do you do? You cut out a piece of paper just large enough for you to write what you need. When you find that you need to add another item to the list you'll have to discard the old piece and cut out a new one. Not very practical, agreed, but you're trying to minimize your paper usage.

As the clever beings that we are we normally make a rough estimate of how big a piece of paper we need and then start writing. The framework, however, has no way of estimating how big a string is going to be. It doesn't know if you're going to concatenate it zero or ten thousand time, so that's something you'll have to estimate yourself.

So what should I do instead?

One word: StringBuilder

The StringBuilder class is made especially for this type of operations. When using the StringBuilder class our sample above would look something like this

private String buildTableSB()
{
   StringBuilder sReturn = new StringBuilder();
   sReturn.Capacity = 8000; // This is optional, but may be very efficient
   int i, j;
   sReturn.Append("<table>");
   for (i = 0; i < 35; i++) // Rows
   {
      sReturn.Append("<tr>");
      for (j = 0; j < 15; j++) // Columns
      {
         sReturn.Append("<td>");
         sReturn.Append(i.ToString());
         sReturn.Append(" : ");
         sReturn.Append(j.ToString());
         sReturn.Append("</td>");
      }
      sReturn.Append("</tr>");
   }
   sReturn.Append("</table>");
   return sReturn.ToString;
}

The difference in performance for a larger operation is enormous. I highly recommend trying out these samples. Copy the functions to a winforms/webforms application, increase the number of rows to 500 and run both versions. The StringBuilder version will finish within milliseconds, and the "classic" version will not... For additional tidbits, take a look at the GC counter in performance monitor and look at how many GCs you have to make to complete the operation.

Bye for now / Johan

Finalizers and weak references

JohanS — Thu, 26 Apr 2007 17:25:57 GMT

What do finalizers and weak references have in common? Well more than you might think actually.

Finalizers

Finalizers are clean-up code that will be run at the end of an objects life-cycle. You should only release native resources in the finalizer. When you use your object you should not the finalizer cleaning up after you. You're much better off performance-wise by making your object Disposable and making sure that you're actually calling the Dispose method. The finalizers should only be the final fail-safe in case the Dispose call is forgotten.

Having a finalizer means your object is always promoted at least one generation by the Garbage Collector (GC). Here's why:

You have an object with a finalizer and the object is no longer referenced
The GC comes to collect the object. It sees that the object has a finalizer. The GC therefore adds the object to the finalizer queue and promotes it one generation on the heap
The finalizer is run, once the finalizer thread is available. (If this takes too long the object might actually be promoted a second time.)
The object is finally garbage collected

Since you only have one finalizer thread and rely heavily on finalizers you may be creating an unintentional bottleneck.

So shouldn't I use finalizers?

Well sure you should. But as I've said before, only regard them as a fail-safe. Make your objects disposable and add a finalizer just in case somebody less skilled than yourself forgets to call the Dispose method. :-)

Weak References

A weak reference is different from a strong reference since this reference is disregarded when the GC comes to collect the object, so if there are nothing but weak references remaining for an object when the heap is GC' d the object will be collected. Weak references are generally useful in two ways:

1. Poor mans cache

If you have a weak reference to an object, say a dataset that takes some time putting together, then you can still work with that object as long as it hasn't been garbage collected. You would work with the reference as you would with any cached item. First you check if the object still exists, if it does, then you get a strong reference to the object and work with it. If not, then you create a new dataset and and work with that one.

2. Custom finalizer

Consider the following scenario. (No, you're not having Déjà Vu. This is the same scenario I described in the finalizers section above.):

You have an object with a finalizer and the object is no longer referenced
The GC comes to collect the object. It sees that the object has a finalizer. The GC therefore adds the object to the finalizer queue and promotes it one generation on the heap
The finalizer is run, once the finalizer thread is available. (If this takes too long the object might actually be promoted a second time.)
The object is finally garbage collected

Here's an alternative way of doing the same thing:

You don't use a finalizer. Instead you have an array of weak references to objects that you occasionally check
When you find that one of the weak references' target is null that means the GC has collected that object
The object has been garbage collected, so now you run your own clean-up code.

Okay, so the second alternative has two obvious benefits compared to the first:

Your object won't be automatically promoted to generation 1 or generation 2.
You won't be depending on the finalizer thread being available to run your clean-up code.

The ultimate option would off course be to have your object being Disposable, make sure you call the Dispose method and use alternatives one or two as back-ups.

Long Weak References

Long weak references will survive the finalizer, so even if your object has been finalized you can still reference it. This may be useful in certain situations, but it can be risky if you're not 100% sure what the finalizer does. Let's say your object performs some kind of file I/O and all file references are closed by the finalizer. If you reference this object using a Long Weak Reference you will have an instance of the object with all I/O functionality disabled. Obviously this could cause all sorts of exceptions if you don't know what you're doing.

Myths and Facts

I've previously gotten some positive feedback on the Myth / Fact format, so I thought I'd round this topic off by adding a summary using that format. Here goes:

Myth:
You can pretty much do anything in the finalizer.

Fact:
The only thing you should do in the finalizer is to release your native resources. The reason why your doing this is because you can never be sure that the person using your object is smart enough to call the Dispose method. If everybody did do that, then we wouldn't need the finalizer at all

Myth:
If you have a finalizer you don't need to make your component disposable

Fact:
You should always call the Dispose method of any disposable object. It doesn't matter if all it seems to do is set GC.SuppressFinalize(Me). That is no guarantee that the next version of the object won't do all kinds of stuff in the Dispose method. The rule of thumb is: If it is disposable, dispose it.

Myth:
Having a finalizer has no impact on performance. When the Garbage Collector (GC) comes to collect it the GC will simply call the Finalize method first and then collect it.

Fact:
Having a finalizer is a guarantee that your object will be promoted one generation before it is collected by the GC. When the GC comes across an object with a finalizer that is ready to be collected it puts the object in the finalizer queue, but the object is then moved to the next generation. For more information on this, please see my previous post on the managed heap, the GC and its generations. You also have only one finalizer thread, so this has bottleneck warning written all over it.

Myth:
Long Weak References are available as long as the object is in the finalizer queue, but they're released once the Finalize method is called.

Fact:
Nope. They are available when they're in the finalizer queue, but they're also available after the finalizer has been called. You really should be aware of this or you might get the strangest results.

Jedi skills

If you want to know more about finalizers, weak references, the GC and other goodies I highly recommend checking out Maoni's WebLog. What better place to learn about this than from one of the developers?

Over and out

/ Johan

Memory management in the .NET Framework

JohanS — Fri, 20 Apr 2007 16:07:29 GMT

This is a subject that has been covered before and I have no intention of writing the ultimate post on the subject. Still I think this is something that every good developer should know.

Why do I need to know this?

My colleagues and I are quite often asked about the necessity of knowing how the Garbage Collector (GC) works. After all, it isn't really necessary to know what's going on behind the scenes, right..? A developer shouldn't have to bother about how the framework works..? Or should he..?

Well you may be a pretty good bus driver even if you know nothing about engines. Basic stuff like not stepping on the break and the gas at the same time is probably enough. If you want to do F1 racing, on the other hand, you will want to know as much as you can about your car. So, if you're content doing small scale web applications or not so efficient winforms applications, then you probably don't have to bother. If you want to do front-line work, then you've got to get your hands dirty.

The different generations

In order to be effective the managed heap is trying to figure out which objects it can disregard and only check up on occasionally. Some objects may span the entire lifecycle of the application and others may be very short lived, so if an object stays alive for a longer period of time the GC will check up on it less frequently. This is accomplished by dividing the managed heap into three generations. Generations 0, 1 and 2. An object will begin in generation 0 and if it is in use for a long period of time it will travel through generations 0 to 2. A possible metaphor for this scenario would the following:

You're asked to call a customer. You're pretty good with numbers so you keep the phone number in your head. (Generation 0)
There is no reply and so you need to remember the phone number a little longer. Meanwhile you're given additional numbers to call.
You know from past experience that your limit for keeping numbers in your head is 10, so once you reach that critical point you decide to write down the numbers you still need on post-it notes (Generation 1)
As the day goes on you keep transferring numbers from memory to post-its.
Your desktop has now reached maximum capacity. It is cluttered with post-it notes, so you sort through them, determining which notes you still need. You throw away the ones that are obsolete and write down the remaining to your address book. (Generation 2)

Like I stated above; when an object is created it is put in Generation 0. The initial size limit of Generation 0 is determined by the size of the processor cache. This is dynamically changed depending on the allocation rate of the application. Once Generation 0 reaches its limit it will go through all the items in Generation 0, tag the obsolete objects for collection and remove them. This is called the Mark and Sweep phase. Everything that survives this sweep will be compacted and moved to Generation 1. The size limit of Generation 1 is also determined by the allocation rate of the application, and once it is reached a Generation 1 collection will occur. This will first mark and sweep all items in Generation 1, moving the surviving items to Generation 2, and then mark and sweep the items in Generation 0.

The healthy ratio between GC's in the different generations is approximately 100 - 10 - 1, so for 100 Generation 0 GC's you normally have 10 GC's of Generation 1 and 1 of Generation 2. A normal Generation 0 GC usually takes a few milliseconds. Performing a GC of Generation 1 rarely takes more than 30 milliseconds, but a Generation 2 collection can take quite some time depending on the application.

The Large Object Heap

To top it off we also have what is called "The Large Object Heap" (LOH). This is where anything larger than 85.000 bytes will be stored. The LOH is collected each time a new segment needs to be reserved (see below), but it is not compacted like generations 0, 1 and 2. When you perform a collection on the LOH you will also perform a GC on the other generations.

Now, if the limit is at 85.000 bytes, won't most of my objects end up on the LOH? - Well not necessarily. For example: A dataset may contain lots and lots of data, but the dataset object only contains references to other objects. The data in the columns are each stored in individual strings and as long as they're not larger than 85 KB you're clear.

Memory segments

The managed heap will reserve memory in segments. The size of the segments depend on the configuration. If <gcServer enabled="true"/> you will reserve memory in 64 MB segments, otherwise you'll be doing it in 32 MB segments. LOH are reserved in 16 MB segments. Only Generation 2 and the LOH will span several segments.

What happens during GC?

Let's say we're performing a full GC, including the LOH. This is what happens:

The objects on the LOH are Marked. Each item in the LOH is checked for references. If none are found it's ready to be collected.
The LOH is Swept. All marked objects are released from memory.
The LOH is not compacted.
Generation 2 is Marked.
Generation 2 is Swept.
Generation 2 is compacted. (Imagine removing a few books from your bookcase, and then pushing the remaining books together freeing up continuous space at the end.)
Generation 1 is Marked.
Generation 1 is Swept.
Everything that survived the sweep is compacted.
The pointer for where Generation 2 ends is updated. Everything that survived the sweep is now Generation 2.
Generation 0 is Marked.
Generation 0 is Swept.
Everything that survived the sweep is compacted.
The pointer for where Generation 1 ends is updated. Everything that survived the sweep is now Generation 1.

A few quick tips

This topic could off course be a lot bigger, but here are some quick suggestions.

Try to stay out of Generation 1

Well off course Generation 1 is better than Generation 2, but you should aim for keeping only a select few objects in Generation 2. Those should be variables that are defined at the beginning of the application lifecycle and released at the end. In an ideal world all other variables should be of the hit-and-run variety and never leave Generation 0.

Don't call GC.Collect()

This has been said before. It will be said again, and again, and again. You should almost never call GC.Collect() manually. And by almost I mean once in a lifetime, not once per application, and certainly not once per function call. I occasionally call GC.Collect() for testing purposes just to see if memory has been released. Normally you would never call it. The GC is self-balancing and by calling GC.Collect() you are disrupting that balance. Think of it as tampering with the eco-system, pouring sugar in the gasoline or whatever metaphor you prefer. :-)

Avoid large objects

If you can stay below the 85.000 byte limit, then do so. If not, consider reusing the object. When it comes to large objects it's better to use one for a long time than to use many for short periods of time.

Don't use finalizers

When your object has a finalizer the finalize method will be called when the object is no longer alive. So far so good. Unfortunately your object will be passed into the next generation, since it's not yet ready to be collected. This means that all objects with a finalizer will at least end up in Generation 1. Most likely in Generation 2.

Well, as I said: There is a lot more to cover on this. There are books to be written and songs to be sung, but you've got to draw the line somewhere. I will most certainly cover more of this in future posts.

/ Johan

I am getting OutOfMemoryExceptions. How can I troubleshoot this?

JohanS — Thu, 11 Jan 2007 19:46:47 GMT

Problem:

You've written an ASP.NET application that is getting OutOfMemoryExceptions.

Cause:

Let's find out...

Resolution:

Use Windbg to take a look at the heap.

Is it a leak?

Take a look at the memory usage of you application using perfmon. If memory is slowly increasing and never released, then you have a leak. If it is going up and down like a rollercoaster, then you are most likely using huge amounts of memory for certain operations which is later garbage collected.

How do I troubleshoot this?

Below I'll try to give you a step by step description of how to troubleshoot this scenario

1. Get a memory dump

This is done using Windbg and Adplus. If you don't have Windbg installed, check out my previous post.

2. Open up the dump and load SOS

Open the dump in Windbg and load the SOS extension. You'll find it in the framework directory so if you're debugging an application for Framework 2.0 look in "C:\Windows\Microsoft.NET\Framework\v2.0.50727". Anyway, load SOS by typing:

.load [path]\sos

3. Run dumpheap

Execute the following command:

!dumpheap -stat

It will show statistics for the objects on the heap in a nice little summary divided in tho four columns.

The method table of the object
The number of objects of this type on the heap
The total size of these objects in bytes
The name of the object type

Be careful not to omit the -stat parameter. If you do then Windbg will dump the address of each object in the entire heap to your screen, which will be a lot of information to say the least.

Analyzing the information provided by !dumpheap

Here's a sample heap from one of my cases...

0:000> !dumpheap -stat
Statistics:
MT             Count       TotalSize Class Name
7a787cc4           1              12 System.IO.FileSystemWatcher+FSWAsyncResult
7a75904c           1              12 System.Diagnostics.OrdinalCaseInsensitiveComparer
7a7575cc           1              12 System.CodeDom.Compiler.CodeDomConfigurationHandler
7a7571a8           1              12 System.Net.DefaultCertPolicy
7a75661c           1              12 System.Diagnostics.TraceListenerCollection
7a755834           1            12 System.Diagnostics.PerformanceCounterCategoryType
........CONTINUED.........
68a66a88     227,559      12,743,304 System.Web.UI.WebControls.Literal
68a2f7fc     399,272      14,373,792 System.Web.UI.ControlCollection
68a92e2c     768,731      33,824,164 System.Web.UI.Control+OccasionalFields
68a884a0     641,952      38,517,120 System.Web.UI.LiteralControl
79124228     879,515      43,394,976 System.Object[]
790fa3e0   1,431,594     122,806,484 System.String

Total 10,389,625 objects, Total size: 463,313,540

So in this particular dump I have 1,431,594 strings whose total size is 122 MBytes, 879,515 Objects with a total size of 43 MBytes, etc.

Objects in heap may be larger than they appear

The TotalSize column isn't 100% true. Look at the LiteralControls that are on third place. They only use a total of 38 MBytes, or do they? The TotalSize refers to the object structure, but the member variables like strings, integers and other child objects are not included. It kind of makes sense, since otherwise the Total size would be completely off the scale. The LiteralControl objects contain a number of child objects and three of those are strings. Their respective size is listed with the System.String object.

Using !dumpobj

Let's take a closer look at one of the System.Web.UI.LiteralControls. We list all of the controls with the following command !dumpheap -type System.Web.UI.LiteralControl and quickly press Ctrl+Break before the screen fills with too many lines:

0:000> !dumpheap -type System.Web.UI.LiteralControl
Address       MT Size Gen
023ea0a8 68a884a0   60   2 System.Web.UI.LiteralControl
023ea0e4 68a884a0   60   2 System.Web.UI.LiteralControl
023ea374 68a884a0   60   2 System.Web.UI.LiteralControl
023ea460 68a884a0   60   2 System.Web.UI.LiteralControl
023ea510 68a884a0   60   2 System.Web.UI.LiteralControl
023eab3c 68a884a0   60   2 System.Web.UI.LiteralControl
........CONTINUED........
023fe31c 68a884a0   60   2 System.Web.UI.LiteralControl
023fe414 68a884a0   60   2 System.Web.UI.LiteralControl
023fe4c4 68a884a0   60   2 System.Web.UI.LiteralControl
023fe500 68a884a0   60   2 System.Web.UI.LiteralControl

As you can see each LiteralControl is 60 bytes in size. Like I said before that's the size of the object structure alone, not it's referenced objects and properties. We now pick the address of one of the LiteralControls and execute the !dumpobj command (!do for short). This gives us the following result:

0:000> !do 023ea0a8
Name: System.Web.UI.LiteralControl
MethodTable: 68a884a0
EEClass: 68a88428
Size: 60(0x3c) bytes
GC Generation: 2
(C:\WINDOWS\assembly\GAC_32\System.Web\2.0.0.0__b03f5f7f11d50a3a\System.Web.dll)
Fields:
      MT    Field Offset                   Type   VT     Attr    Value Name
790fa3e0 4001fe0      4          System.String    0 instance 00000000 _id
790fa3e0 4001fe1     8          System.String    0 instance 00000000 _cachedUniqueID
68a2af44 4001fe2     c   ...em.Web.UI.Control    0 instance 023e8864 _parent
68a91070 4001fe3     2c           System.Int32    0 instance        0 _controlState
68a85ea0 4001fe4     10   ...m.Web.UI.StateBag    0 instance 00000000 _viewState
68a2af44 4001fe5     14   ...em.Web.UI.Control    0 instance 023e8864 _namingContainer
68a273d0 4001fe6     18     System.Web.UI.Page    0 instance 01df4514 _page
68a92e2c 4001fe7     1c   ...+OccasionalFields    0 instance 00000000 _occasionalFields
68a2b378 4001fe8     20   ...I.TemplateControl    0 instance 00000000 _templateControl
68a14528 4001fe9     24   ...m.Web.VirtualPath    0 instance 00000000 _templateSourceVirtualDirectory
68a8bb48 4001fea    28   ...rs.ControlAdapter    0 instance 00000000 _adapter
68a3a8f8 4001feb    30   ...SimpleBitVector32    1 instance 023ea0d8 flags
790f9c18 4001fda    c70          System.Object    0   shared   static EventDataBinding
>> Domain:Value 000f0d00:NotInit 0011a720:01df0028 <<
790f9c18 4001fdb    c74          System.Object    0   shared   static EventInit
>> Domain:Value 000f0d00:NotInit 0011a720:01df0034 <<
790f9c18 4001fdc    c78          System.Object    0   shared   static EventLoad
>> Domain:Value 000f0d00:NotInit 0011a720:01df0040 <<
790f9c18 4001fdd    c7c          System.Object    0   shared   static EventUnload
>> Domain:Value 000f0d00:NotInit 0011a720:01df004c <<
790f9c18 4001fde    c80          System.Object    0   shared   static EventPreRender
>> Domain:Value 000f0d00:NotInit 0011a720:01df0058 <<
790f9c18 4001fdf    c84          System.Object    0   shared   static EventDisposed
>> Domain:Value 000f0d00:NotInit 0011a720:01df0064 <<
79124228 4001fec    c88        System.Object[]    0   shared   static automaticIDs
>> Domain:Value 000f0d00:NotInit 0011a720:01df0070 <<
790fa3e0 4002211     34          System.String    0 instance 02238664 _text

Cool, now we can take a look at the specifics. For example the value of the text-property, which is located in the string down at the bottom with address 02238664. To get it's value, simply perform a !do on the address:

0:000> !do 02238664
Name: System.String
MethodTable: 790fa3e0
EEClass: 790fa340
Size: 158(0x9e) bytes
GC Generation: 2
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: </td>
</tr>
</table>


Fields:
MT Field Offset Type VT Attr Value Name
790fed1c 4000096 4 System.Int32 0 instance 71 m_arrayLength
790fed1c 4000097 8 System.Int32 0 instance 70 m_stringLength
790fbefc 4000098 c System.Char 0 instance 3c m_firstChar
790fa3e0 4000099 10 System.String 0 shared static Empty
>> Domain:Value 000f0d00:790d6584 0011a720:790d6584 <<
79124670 400009a 14 System.Char[] 0 shared static WhitespaceChars
>> Domain:Value 000f0d00:01d413b8 0011a720:01d44f80 <<

Okay, so we can see that the string contains some data to close off a table. We can also take a look at the other properties for the object and examine them if we wish. But there is another command that is really useful...

Using !objsize

Is there a way to get the total size of a specific System.Web.UI.LiteralControl? - Simple! We use the !objsize -command. !objsize looks at all the pointers within an object and calculate their total size. Below is the built in documentation for the !objsize -command:

0:000> !help objsize
-------------------------------------------------------------------------------
!ObjSize [<Object address>]

With no parameters, !ObjSize lists the size of all objects found on managed
threads. It also enumerates all GCHandles in the process, and totals the size
of any objects pointed to by those handles. In calculating object size,
!ObjSize includes the size of all child objects in addition to the parent.

For example, !DumpObj lists a size of 20 bytes for this Customer object:

0:000> !do a79d40
Name: Customer
MethodTable: 009038ec
EEClass: 03ee1b84
Size: 20(0x14) bytes
(C:\pub\unittest.exe)
Fields:
MT         Field Offset Type              Attr    Value  Name
009038ec 4000008      4 CLASS          instance 00a79ce4  name
009038ec 4000009      8 CLASS          instance 00a79d2c bank
009038ec 400000a      c System.Boolean instance        1 valid

but !ObjSize lists 152 bytes:
0:000> !ObjSize a79d40
sizeof(00a79d40) = 152 ( 0x98) bytes (Customer)

This is because a Customer points to a Bank, has a name, and the Bank points to
an Address string. You can use !ObjSize to identify any particularly large
objects, such as a managed cache in a web server.

Objects in heap may also be smaller than they appear

So what do we get if we run !objsize on our LiteralControl? This is really interesting, because what happens is; the debugger gets really busy for quite some time and eventually we get this:

0:000> !objsize 023ea0a8
sizeof(023ea0a8) = 456918136 ( 0x1b3c0478) bytes (System.Web.UI.LiteralControl)

456 MBytes! How is that possible? Well if you scroll up to where we ran the !do command on the LiteralControl, you'll see that the control holds a reference to the page. The page in turn has a reference to the cache, and before long we'll have referenced almost the entire heap.

Summary

Hopefully this is enough to give you a quick glimpse of what is possible with three relatively simple commands from the sos extension. The commands were:

!dumpheap
!dumpobj
!objsize

Over and out

/ Johan