Why classes with finalizers need more than one garbage collection cycle?

Question

This article says

If an object has a finalizer, it is not immediately removed when the garbage collector decides it is no longer ‘live’. Instead, it becomes a special kind of root until .NET has called the finalizer method. This means that these objects usually require more than one garbage collection to be removed from memory, as they will survive the first time they are found to be unused.

My question is why GC don't call finalizer when it finds that object can't be referenced anymore and collect the object right away? why does it need more than on garbage collection?

Answer 1

Two points to consider:

• The finalizer may take some time to complete. For example, it may end up closing a resource or something similar. You wouldn't want that to be part of the garbage collection time, which may be blocking threads from doing work (when they just want to get some memory). By running finalization separately, the GC itself can complete very quickly, and the finalization work can be done in parallel with other work later.

• The finalizer may resurrect the object by making it visible again - but detecting that would (I suspect) require another sweep of memory anyway... so why not just wait until the next time it was going to happen?

Answer 2

Because (depending on the GC mode selected) when it is performing GC it has to pause key parts of the runtime. Hence you want this to be as quick as is possible. This creates two issues:

1. it doesn't know how long the finalizer will take to run (although it has a hard limit), and doesn't want to delay resuming the runtime
2. the runtime needs to be running for the finalizer to work reliably (even if a GC thread is used, the code you write could conceivably care about other threads)

To address both issues, those with pending finalizers are queued, and then executed after the GC has finished (when the runtime is working).

As a side-note, it is a good practice to combine finalizers with IDisposable and have the Dispose() cancel the finalization; that way it doesn't need finalization later, and is cleaned up in one step.

Answer 3

When the .net garbage-collector runs, objects are divided into three categories: objects which are reachable from a "normal" rooted reference, objects which are not reachable by any rooted reference, and objects which are not reachable by any "normal" rooted reference, but have either requested to receive notification when they are abandoned, or are reachable from other objects that have done so. The garbage collector makes a list of objects in that third category; that list is stored as a rooted reference, making all objects in it 'live'. The system goes through items in that list, though, cancels their 'notification' requests, runs their Finalize() method, and removes them from the list. If no reference to the object exists anywhere once all that is said and done, then the object will be declared "dead" on the next GC cycle.