Finalization Uncovered

I’ve talked about finalization before but based on seeing questions related to it it appears that it deserves some clarification.

First of all, finalization is a mechanism we provide in the CLR wheras Dispose is a programming pattern. See Clearing up some confusion over finalization and other areas in GC for an explanation why we provide finalization. Inside of the GC, it’s completely not aware of Dispose. People often call GC.SuppressFinalize in their Dispose implementation but that’s just a choice they make when they write code. I will explain exactly what GC.SuppressFinalize does in a bit. Oh and I am not the owner of the “Dispose pattern” J

So what happens when you allocate an object with a finalizer? GC’s allocator will get called and it’s told this object is finalizable. So if GC can successfully allocate this object it will then record that this is a finalizable object. GC maintains a list to record finalizable objects so a new object will be in the gen0 part of that list. Recording just means writing the object address X to an entry in the gen0 part.

When GC promotes a finalizable object to another generation, it’ll move its address to the part of the list for that generation. Of course when the object is compacted we also need to update the entry in the finalize list with the new address.

When GC finishes marking objects, ie, it has determined which ones should be live, it will look at the list for the generation it’s collecting see if those objects are dead. For the dead ones it will then promote that object and move the address to the part of the list that’s for “ready for finalization” objects. If any of such objects are found, GC will signal to the finalizer thread that there’s work to do.

When the managed threads are restarted after GC is done, since the finalizer thread is also a managed thread, it also gets restarted and starts to do its work – running finalizers. It does this by asking for the entries in the “ready for finalization” part of the list. Those entries are removed from the list as the objects’ finalizers are run.

If you do a !finalizequeue you will see output like this:

0:015> !finalizequeue
SyncBlocks to be cleaned up: 0
MTA Interfaces to be released: 0
STA Interfaces to be released: 0
----------------------------------
------------------------------
Heap 0
generation 0 has 971 finalizable objects (000000000e31b958->000000000e31d7b0)
generation 1 has 346 finalizable objects (000000000e31ae88->000000000e31b958)
generation 2 has 139 finalizable objects (000000000e31aa30->000000000e31ae88)
Ready for finalization 0 objects (000000000e31d7b0->000000000e31d7b0)
------------------------------
Heap 1
generation 0 has 2686 finalizable objects (000000000d41aa10->000000000d41fe00)
generation 1 has 473 finalizable objects (000000000d419b48->000000000d41aa10)
generation 2 has 129 finalizable objects (000000000d419740->000000000d419b48)
Ready for finalization 0 objects (000000000d41fe00->000000000d41fe00)
------------------------------
Heap 2
generation 0 has 319 finalizable objects (000000000d298298->000000000d298c90)
generation 1 has 302 finalizable objects (000000000d297928->000000000d298298)
generation 2 has 241 finalizable objects (000000000d2971a0->000000000d297928)
Ready for finalization 0 objects (000000000d298c90->000000000d298c90)
------------------------------
Heap 3
generation 0 has 147 finalizable objects (000000000c982998->000000000c982e30)
generation 1 has 432 finalizable objects (000000000c981c18->000000000c982998)
generation 2 has 147 finalizable objects (000000000c981780->000000000c981c18)
Ready for finalization 0 objects (000000000c982e30->000000000c982e30)

As you can see, there are “Finalizable” objects and “Ready for finalization” objects, as we talked about above.

Read more: Maoni's WebLog

Posted via email from .NET Info