From this output we can see all of the objects that have been created that have a finalize method. If you call dispose on the object and it ends up calling GC.SuppressFinalize, then it will still be in this list, but will be able to be collected like an object that does not need to be finalized. So other then those objects, these are all of the objects that will need to be finalized. After each heap you will see a line about Ready for finalization… this show how many of the objects will need to run on the finalize thread currently. If you use the sos that comes with the debugger package (works only with 1.x version) you can add the -detail switch and see the Freachable Queue which is all of the objects that are ready to be finalized (GC.SuppressFinalize wasn't called but the object is ready to be cleaned up) as seen here:
When you see the !finalizequeue list showing thousands of objects, that is usually a sign that too many objects have a finalizer. The best way to troubleshoot this is to look for objects that are not part of the framework and then make sure that they follow the rules we discussed earlier.
There are other things that can go wrong with the finalizer but we will discuss them later. Some are already discussed on Tess’s blog.
A useful link about writing faster code is here. This also talks about calling GC.SuppressFinalize. There are also some very useful information in the following posts: