Is it appropriate to call GC.Collect in a finalizer?

Question

We have a BitmapImageclass that wraps a native image id and System.Drawing.Bitmap and implements IDisposable. The image id is created as part of a third-party imaging SDK we use that uses integers to identity an "image" pointing to some pixel data. Both the image id and bitmap point to the same underlying pixel data.

The SDK is very difficult to use correctly in many cases, so we have a facade layer that abstracts away the SDK and provides an easy to use and error-less API, for TIF and PDF documents, and part of this is to guarantee that memory is freed as soon as possible. 300 DPI multi-page images with hundreds of pages are common place, so memory can easily be high in the application.

We are currently calling GC.Collect in the Dispose method to free up the memory immediately. After thorough testing of the software, this was the only way to free up large amounts of memory immediately after releasing the underlying pixel data, especially during a large merge operation where we might be merging several hundreds of pages together in a document. It is also implemented this way so developers do not incorrectly try to scatter their code with GC.Collect, because they should not really be calling it anyway.

My question is two parts:

• When a finalizer is called by the garbage collector, does it also free the memory immediately, or could there be a long period of time before this occurs? Should we call GC.Collect here as well? Especially in only a 32-bit process, we must ensure we are keeping as much free memory as possible.
• The SDK we use is GdPicture, and even when you Dispose of their graphics object, it does not dispose of the pixel data or image references. It leaves them around until a developer frees them. We need to guaruntee that if a developer does not call Dispose manually, that the resources are freed. Is it appropriate to reference a managed class in a finalizer, such as GraphicsObject.ReleaseImage(id)? I read in some places that you should not call methods other than some of the static ones from things like SafeHandle, but unless we call this the memory will not be freed

Answer 1

I think there's a bit mess. Want to make it more clear in common understanding.

You can't manage time for GCollection.

GC-n occurs when: System has low physical memory + Memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. This threshold is continuously adjusted as the process runs. + GC.Collect method is called. In almost all cases, you don’t have to call this method, because GC runs continuously. GC.Collect method is primarily used for unique situations and testing.

GC optimizing engine determines best time to perform a collection, based upon allocations being made. Exact time when Finalizer executes is undefined. To ensure deterministic release of resources for instances of class, implement a Close() method or provide an IDisposable.Dispose implementation + The finalizers of two objects are not guaranteed to run in any specific order + Thread on which the finalizer runs is unspecified. For case someone forget to Dispose use Destructor

~ YourClass(){Dispose(false);}

is transformed into:

protected override void Finalize() { try { … cleanup…} finally { base.Finalize(); } }

• Don't forget to

YourClass : IDisposable

It's ("Finalizer") used to perform cleanup operations on unmanaged resources held by current object before object is destroyed by GC. Method is protected and therefore is accessible only through this class or through a derived class. By default (when use ~), GC automatically calls an object's finalizer before reclaiming its memory.

GC adds an entry for each instance of the type to an internal structure finalization queue - an internal data structure (Queue) controlled by GC. Finalization queue contains entries for all objects in managed heap whose finalization code must run before GC can reclaim their memory. When GC finds objects to be garbage, it scans Finalization Queue looking for pointers to these objects. If a pointer is found, it is removed from Finalization Queue and added to Freachable Queue. Object is no longer considered garbage and its memory is not reclaimed. At this point, GC has finished identifying garbage. Special runtime thread empties the Freachable Queue, executing each object's Finalize method. Normally when Freachable Queue is empty, this thread sleeps.

You need minimum 2 GCollections for objects with destructor (That's why in Dispose pattern GC.SuppressFinilise(this) is used - you say to GC that don't move object to Generation_1 or Generation_2, that memory might be reclaimed as GC meet destructor) + (that also means that objects with finalizers are moved minimum to Generation_1, that GC checks about 10 times rarely (than Generaation_0) that means that objects you don't need stay in memory longer)

Suggest to apply or

using(...)

that transforms into

try { … } finally { XX.Dispose();}

or implement correctly IDisposable interface using IntPtr structure for unmanaged resources (it works with different architecture (32 or 64)). Do not recommend to use SafeHandle (Interopservices) because it works only with Win32 architecture (good in SafeHandle is that you don't need to implement IDisposable as it inherits from CriticalFinalizerObject)

Classic implementation of IDisposable when you don't need to care if someone forget to Dispose object (for that case you have ~ destructor):

For base class

public MyClass() { this.reader = new TextReader(); }

public class A : IDisposable   
{
    bool disposed = false;  // Flag: Has Dispose already been called?
    private Component handle;
    private IntPtr umResource;
    public void Dispose()   {      
                Dispose(true);   GC.SuppressFinalize(this);   }
    protected virtual void Dispose(bool disposing) {
                if (disposed) return;
                if (disposing) {            // Free managed resources
                        if (reader != null) reader.Dispose(); 
                        if (handle != null) handle.Close(); }
                if (umResource != IntPtr.Zero) { // Free unmanaged resources
                            umResource = IntPtr.Zero; }
                disposed = true;   }  
    ~A() { Dispose(false); }   } // Only if we have real unmanaged resources

For derived class

public class B : A  {
        private bool disposed = false;
        protected override void Dispose(bool disposing)  {
                    if (disposed) return;
                    if (disposing) {  ... }     // To free any managed objects 
                                               // Free unmanaged resources
                    disposed = true;     
                    base.Dispose(disposing)}   }

disposing false – call comes from Finalizer; disposing true – from Dispose (from you)

Sorry, forgot to RESUME:

** Use GC.Collect to force the system TO TRY to reclaim the maximum amount of available memory. You can also point out to GC which generations you want it to check. BUT AS I WROTE IN THE BEGINING - YOU HAVE NO CONTROL, even if you use GC.Collect - that doesn't guarantee anything (GC may override your call, etc), but you can try and it wouldn't bring any problems **

Answer 2

As a general rule, you should not have GC.Collect in productive code. It can help for debugging (if you want to see if a memory spike is temporary). But generally it is better to leave the GC to it's own devices. It is about as optimized as it can be. Even when it is not collecting, it is doing something effective (waiting if maybe application closure will make it's job a lot simpler). If you want to affect the major behavior, change teh GC strategy for the application instead.

The 2nd part of your question is about the Dipose/Finalize pattern. There are two cases:

• You only handle stuff that implements IDisposeable. In this case all you need to do is Implement Dispose. And all it needs to do is to relay the "Dispose" order to anything Disposeable it contains.
• You actually handle Unamaged resources. In this case you should first implement the Finalizer (so at least the GC can clean this up at applicatin closure/collection). Then you provide the Dispose function as additional thing. But I would always put the Finalizer first, because it will be called with guarantee.

Finalizer and Dispose are largely indentical. So identical it is customary to just write the Dispose function with a boolean switch. The only things in wich Finalizer and Dispose actually differ is the "relay" part: - If applicable you always relay a Dispose call to contained instances. Because that is the common usecase for Dispose (relaying teh call of Dispose()). It is better if we all adhere to it. - You never relay a fianlizer call to contained isntances. Finalization is between that instance and the GC.

About 95% of the cases you only need dispose.

Calling GC.Collect in the Finalizer makes no sense. The finalizer is about cleaning up unmanaged resources. The ones the GC does not govern.

GC Collect is just "do the collection of managed resources now". They apply pretty much to opposite cases (managed vs unamanged resources).