What did you do with my resources?

‘.”n”;
}
add_action(‘wp_head’, ‘mypage_head’);
?>

I spent a good chunk of my day today really trying to learn about .NET Garbage Collection because as I had found I was under a lot of misconceptions/misunderstandings of how it works.

Dispose()

I was mistaking this for something similar to a destructor which in C# is the finalize method. This method is defined for any class that inherits from the IDisposable Interface. Implementing the interface allows you to also declare the object with the “using” keyword.
The purpose of this method is to provide the programmer a chance to “clean up” the object properly before they are released especially if they have references to unmanaged code (Window handles etc..)

The part where I was thrown off and took a long time reading to understand and learn is that in most cases (pretty much all if done correctly) you still don’t need to call Dispose on the object.

For instance, say you have a managed object with an unmanaged member variable. If the Dispose design method is implemented properly there should be a Finalize method that is declared which calls Dispose () anyways.

But remember, C# doesn’t support destructors. Don’t let the identical syntax fool you.

The problems begin to creep up in doing this in a efficient way. Thankfully .NET provides all the functionality needed to properly do this. When a class implements a finalize method, the way in which it gets garbage collected is differently than other items (Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework).In short, it gets put on a different queue which can result in a large performance cost.

The following example from MSDN shows how to properly implement the Dispose pattern:

You can see how using this proper dispose pattern, if Dispose() was called by the programmer the finalize method is suppressed removing the need to call it again which would essential attempt to clean up the resource twice and we reattain the lost performance.

So I am in the woods on when someone would have to or would actually want to call Dispose on an object considering the GC will eventually call it for me anyways and the following:

What doesn’t happen when you call Dispose():

  1. Calling Dispose does not prioritize the object for garbage collection. It simply unloads the object’s (unmanaged) resources from memory.
  2. Calling Dispose does not deallocate the object from memory. Only the GC does that when it performs a collection of the generation in which the object resides.
  3. The CLR does not insert or run any code not in Dispose. The behaviour of Dispose is defined by the developer.
  4. Dispose must be called explicitly by the application. It is never called by the runtime. The only exceptions are when using C#’s using statement (see ShawnFa’s article for a good explanation of what exactly goes on), and the foreach keyword in C# will result in Dispose being called on the Enumerator
  5. Dispose is NOT threadsafe. This means two threads can call Dispose on the same object at the same time. Like for any other synchronization-sensitive method, take steps to make sure this doesn’t happen. I’ll give an example of when this might happen in the next section.

The oddest aspect as well is that the object is still alive after a call to Dispose (can very well be alive for a long while if the GC is in fact not needed to be called) and can be continued to be used unless the class checks in every method isDisposed which they never do.

Who knew being a garbage could be so fascinating…

Leave a Reply

Your email address will not be published. Required fields are marked *