Keep object on GC destruction attempt

Question

I got this idea while thinking of ways to recycling objects. I am doing this as an experiment to see how memory pooling works and I realize that in 99% of scenario this is very unnecessary .

However, I have a question. Is there a way to force the GC to keep the object? In other words, can I tell the GC not to destroy an object and say instead have new reference created in a list that holds available to use objects? The issue, though I have not tested this, is that if I add something like this to a list:

~myObject()
{
     ((List<myObject>)HttpContext.Current.Items[typeof(T).ToString()]).add(this);//Lets assume this is ASP
}

it will add a pointer to this object into the list, but if the object is destroyed I will get a null pointer exception because the object is no longer there. However, maybe I could tell the GC not to collect this item and thus keeping the object?

I know this is the type of stuff that most programmers would go "why the hell would you do this?". But on the other hand programming is about trying new and learning new things. Any suggestions, thoughts, implementatons? Any help would be greatly appreciated!

Answer 1

Yes, this is legitimate. It is called 'resurrection'. When you assign the this reference to somewhere that is 'live', then the object is no longer considered garbage.

You will also need to reregister for finalization using GC.ReRegisterForFinalize(this), or the next time the object becomes garbage, it will not be finalized (the destructor will not be called).

You can read more about object resurrection in this MSDN Magazine article.

Answer 2

Yes, this is possible and it even has a name: resurrection.

but if the object is destroyed I will get a null pointer exception because the object is no longer there.

Much worse, you would get an invalid pointer (reference) error. And possibly a blue screen or crashing server. But luckily the CLR won't let that happen. Simply putting a doomed instance in any kind of list makes it reachable again and then it will not be reclaimed.

When you want your object to be recycled multiple times you will have to call GC.ReRegisterForFinalize(x) on it.

Most practical answer though: don't do it. The destructor alone accounts for considerable overhead and there are many ways to get this wrong.