SOS's !FinalizeQueue should filter out WeakReferences

[jasonmalinowski]

We were recently looking at a dump where it appeared there was a very large number of objects in the finalizer queue according to the !FinalizeQueue command. Upon further investigation this appeared to be a red herring, since the vast majority of objects are WeakReferences, and those are magic. Basically, they appear as finalizable objects, but they won't be finalized by the queue, but rather cleaned up by the GC.

I'd propose that !FinalizeQueue should just filter out the WeakReferences, since that's effectively what the runtime is doing as well. Otherwise this can result in some confusion of the actual state of your process.

[jkotas]

WeakReferences, and those are magic. Basically, they appear as finalizable objects, but they won't be finalized by the queue, but rather cleaned up by the GC.

You are right that the finalization of WeakReferences is special-cased by the runtime to make it a bit cheaper, but it is far from free.

WeakReference are finalizable object and they incur much of the same costs as any other finalizable type with a cheap finalizer. Their allocation is much slower since they have to be registered for finalization, the GC has to do extra bookkeeping for them, etc.

[jkotas]

those are magic.

Without the magic, the flow is native GC code -> managed finalizer -> native GC handle code. You will get this flow if you inherit from non-generic WeakReference (e.g. class MyWeakReference : WeakReference). The special casing does not kick in for this case to account for the possibility of MyWeakReference having a custom user-provided finalizer.

This special casing short-circuits the managed finalizer step, so the finalization flow is just native GC code -> native GC handle code. A bit cheaper, but far from free.