Question

I’ve recently come across the ConditionalWeakTable<TKey,TValue> class in my search for an IDictionary which uses weak references, as suggested in answers here and here.

There is a definitive MSDN article which introduced the class and which states:

You can find the class … in the System.Runtime.CompilerServices namespace. It’s in CompilerServices because it’s not a general-purpose dictionary type: we intend for it to only be used by compiler writers.

and later again:

…the conditional weak table is not intended to be a general purpose collection… But if you’re writing a .NET language of your own and need to expose the ability to attach properties to objects you should definitely look into the Conditional Weak Table.

In line with this, the MSDN entry description of the class reads:

Enables compilers to dynamically attach object fields to managed objects.

So obviously it was originally created for a very specific purpose – to help the DLR, and the System.Runtime.CompilerServices namespace embodies this. But it seems to have found a much wider use than that – even within the CLR. If I search for references of ConditionalWeakTable in ILSpy, for example, I can see that is used in the MEF class CatalogExportProvider and in the internal WPF DataGridHelper class, amongst others.

My question is whether it is okay to use ConditionalWeakTable outside of compiler writing and language tools, and whether there is any risk in doing so in terms of incurring additional overhead or of the implementation changing significantly in future .NET versions. (Or should it be avoided and a custom implementation like this one be used instead).

There is also further reading here, here and here about how the ConditionalWeakTable makes use of a hidden CLR implementation of ephemerons (via System.Runtime.Compiler.Services. DependentHandle) to deal with the problem of cycles between keys and values, and how this cannot easily be accomplished in a custom manner.

Answer 1

I don’t see anything wrong with using ConditionalWeakTable. If you need ephemerons, you pretty much have no other choice.

I don’t think future .NET versions will be a problem – even if only compilers would use this class, Microsoft still couldn’t change it without breaking compatibility with existing binaries.

As for overhead – there certainly will be overhead compared to a normal Dictionary. Having many DependentHandles probably will be expensive similarly to how many WeakReferences are more expensive than normal references (the GC has to do additional work to scan them to see if they need to be nulled out). But that’s not a problem unless you have lots (several million) of entries.