Costs involved with C# destructors (aka: finalizers)?

Question

The destructor should only release unmanaged resources that your object holds on to, and it should not reference other objects. If you have only managed references you do not need to (and should not) implement a destructor. You want this only for handling unmanaged resources. Because there is some cost to having a destructor, you ought to implement this only on methods that consume valuable, unmanaged resources.

-- Top Ten Traps in C# for C++ Programmers

The article doesn't go into this in more depth, but what sorts of costs are involved with using a destructor in C#?

Note: I know about the GC and the fact the destructor isn't called at reliable times, that all aside, is there anything else?

score 8 · Accepted Answer · answered Mar 05 '09 at 01:51

8

Any object that has a finalizer (I prefer that term over destructor, to emphasize the difference from C++ destructors) is added to the finalizer queue. This is a list of references to objects that has a finalizer that has to be called before they are removed.

When the object is up for garbage collection, the GC will find that it's in the finalizer queue and move the reference to the freachable (f-reachable) queue. This is the list that the finalizer background thread goes through to call the finalizer method of each object in turn.

Once the finalizer of the object has been called, the object is no longer in the finalizer queue so it's just a regular managed object that the GC can remove.

This all means that if an object has a finalizer, it will survive at least one garbage collection before it can be removed. This usually means that the object will be moved to the next heap generation, which involves actually moving the data in memory from one heap to another.

answered Mar 05 '09 at 01:51

Guffa

687,336
108
737
1,005

I'm anticipating that the majority of my objects will only be pulled down and freed at the end of the applications life, how does that affect this? The GC will just run till it's cleared out everything won't it? – Matthew Scharley Mar 05 '09 at 02:05
When the app ends the GC will allow some time for finalizers to run, but eventually it will just tear down the heaps even if all objects are not finalized. If you need some cleanup code to run you should implement the IDisposable interface instead, which gives you control over the object life cycle. – Guffa Mar 05 '09 at 02:20
1

Just to emphasize, when the app is shutting down, .NET only allows a fixed amount of time for finalizers to run. (I think the values are currently something like max 10 seconds per finalizer, and at most 30 seconds for *all* finalizers. Which means it's not guaranteed that all finalizers get to run) – jalf Mar 05 '09 at 03:57

plinth · Answer 2 · 2009-03-05T02:35:28.140

6

The most extensive discussion I've seen on how this all works was done by Joe Duffy. It has more detail than you might imagine.

Following that up, I put together a practical approach to doing this on a day to day - less about the cost but more about the implementation.

edited Mar 05 '09 at 02:35

answered Mar 05 '09 at 01:45

plinth

48,267
11
78
120

If I'm coming from anything, I'm coming from C, although I'm far more proficient in C# than I am in either, I just found the article when I was searching for information on destructors in C#. – Matthew Scharley Mar 05 '09 at 01:49
Actually the C# 3 language specification still refers to them as destructors, so even tough they are nothing like their C++ counterparts they unfortunately still share the name. – Brian Rasmussen Mar 05 '09 at 02:14
Very few classes should have finalizers. Indeed, with rare exceptions, only classes whose primary purpose centers around finalization should have them. Unmanaged resources (responsibilities) that would require finalization should not be held by classes that hold other things; each should be moved into classes whose primary purpose is to hold it and ensure its cleanup (ensure its responsibilities get carried out). Since everything that's referred to directly or indirectly by a finalizable object must be kept until the finalizer runs, finalizable classes should be as lightweight as possible. – supercat Aug 09 '11 at 16:12

score 3 · Answer 3 · answered Mar 05 '09 at 02:24

Guffa and JaredPar cover the details pretty well, so I'll just add a somewhat esoteric note on finalizers or destructors as the C# language specification unfortunately calls them.

One thing to keep in mind is that since the finalizer thread runs all finalizers in sequence, a deadlock in a finalizer will prevent all remaining (and future) finalizers from running. Since these instances are not collected until their finalizers complete a deadlocked finalizer will also cause a memory leak.

score 0 · Answer 4 · edited May 23 '17 at 11:53

Guffa has summed up the factors in the finalizer cost quite well. There was a recent article about the cost of finalizers in Java which also gives some insight.

Part of the cost in .net can be avoided by removing the object from the finalizer queue with GC.SuppressFinalize. I ran some quick tests in .net based on article and posted it here (although the focus is far more on the Java side).

Below is a graph of the results - it doesn't really have the best labels ;-). "Debug=true/false" refers to the empty vs simple finalizer:

~ConditionalFinalizer()  
{  
    if (DEBUG)  
    {  
        if (!resourceClosed)  
        {  
            Console.Error.WriteLine("Object not disposed");  
        }  
        resourceClosed = true;  
    }  
}

"Suppress=true" refers to whether GC.SuppressFinalize was called in the Dipose method.

Summary

For .net, removing the object from the finalizer queue by calling GC.SuppressFinalize is half the cost of leaving the object on the queue.

Costs involved with C# destructors (aka: finalizers)?

4 Answers4

Summary