Object Resurrection

I’m sure many of you have heard the term “object resurrection” with respect to the GC. It’s an interesting (but not very useful) way to illustrate object lifetimes and the role of finalization versus garbage collection. Basically, it’s a way to reference an object that has been finalized.

 

Here’s a rough description of how object resurrection can occur:

 

1. A finalizable object is created. It reachable from user code and is considered “live”.
2. Inside the object’s finalizer is a statement assigning the “this” pointer to a global object (like a static). Since it has a finalizer, a reference to the object is put on the finalization watchlist by the GC.
3. At some point the object’s last strong reference is gone, the object is considered garbage. The object reference is then moved off the finalization watchlist and onto the freachable queue. Now the object is considered live again since it’s referred to by the freachable queue. and the object is considered “freachable”.
4. When the finalizer thread runs the object’s finalizer, the object is removed from the freachable queue. The global object now points to the object, making it once again reachable from user code. The object is said to have been “resurrected” and is once again reachable from user code and considered “live”.

 

Here’s a code sample to illustrate:

public class ResurrectedObj

{

      ~ResurrectedObj()

      {

            // this will resurrect the object by assigning

// it to the static reference

            resurrectedReference = this;

      }

      public static ResurrectedObj resurrectedReference = null;

      public static void Main()

      {

            ResurrectedObj liveReference = new ResurrectedObj();

            liveReference = null;

            GC.Collect();

// liveReference is now dead and the object is put on the

// freachable queue

            GC.WaitForPendingFinalizers();

            // at this point, the object previously referenced

// by liveReference is held alive by resurrectedReference

      }

}

 

Unfortunately there are several implications to object resurrection which may not be immediately obvious. For these reasons we strongly recommend against resurrecting objects.

 

• Once the object has been resurrected, the GC has removed it from the finalization queue. This means when the object dies again, the finalizer will not be run a second time. To ensure the finalizer gets run, a call to GC.ReRegisterForFinalization() is required.
• Attempting to use an object after the finalizer has been run, can result in undefined behavior. Maybe the finalizer released an unmanaged resource, and you try to access it? This is the same reason why you are discouraged from accessing other managed objects from a finalizer: that object’s finalizer may have been run before yours.
• Any object referenced by your resurrected object will also be resurrected. If any of those objects are finalizable, their finalizers may have been run, and may be in an invalid state.
• As with all finalizable objects, multiple garbage collections are required to completely clean up the object, potentially hurting performance and memory usage.

Comments

• Anonymous
  April 27, 2006
  This is all well and good, but when is resurrection used in the real world? In other words, why does it exist, given its many pitfalls and dangers?
• Anonymous
  April 28, 2006
  Hi John
  
  I can't think of any legitamite purpose for object resurrection (of course that doesn't mean there isn't one...).  It exists because the runtime doesn't disallow object assignment in a finalizer.
  
  There's a Channel 9 thread about legitimate uses of object resurrection, which might answer your question:
  http://channel9.msdn.com/ShowPost.aspx?PostID=62453
  
  -Chris
  
  
• Anonymous
  May 01, 2006
  Chris:
  
  Thanks! I'm checking that thread now!