Weak Delegate WPF Observable Collection

Primary Problem Statement and Illustration

A common problem with production-scale WPF applications is memory leaks of GUI objects. This occurs due to the implementation of the Observable pattern in WPF's key INotifyCollectionChanged interfaces. This interface permits a data model object or collection to notify an observer whenever a collection changes with an intuitive and efficient interface. The leak happens whenever a WPF GUI object outlives the data model object it is displaying. For example, given a simple data model object that looks like this:

public class ExampleProvider : INotifyPropertyChanged

{

public event PropertyChangedEventHandler PropertyChanged;

public string Name { get; set; }

public ObservableCollection<string> GroceryItems { get; set; }

}

Let's also assume there is a WPF window (could be a user control too, doesn't matter) that displays this object with a TextBox bound to Name and an ItemsControl bound to GroceryItems. At InitializeComponent, the ItemsControls checks GroceryItems to see if it supports INotifyCollectionChanged and then installs a subscriber on that event so it is notified of any change to the collection. If you then call GroceryItems.CollectionChanged.GetInvocationList() to check the list of installed callbacks, you see one delegate that looks like this:

Method {Void OnCollectionChanged(System.Object, System.Collections.Specialized.NotifyCollectionChangedEventArgs)} System.Reflection.MethodInfo {System.Reflection.RuntimeMethodInfo}

Target {System.Windows.Data.ListCollectionView} object {System.Windows.Data.ListCollectionView}

A C# delegate object has only two members: Method and Target. These determine how to make the requested call. Method identifies the method being called. Target identifies the THIS object to use for that method invocation. Target can be null if this is a static or anonymous method that doesn't reference any instance members. The important point here is that this delegate has a strong (normal) reference to the ItemsControl! Because the ItemsControl is contained by the window object - in other words, in memory, the window object has a list of child objects and the ItemsControl is in that list - the window cannot be garbage collected until this reference to it is removed. Well, that's no problem, you may say. When the window is closed, it will unsubscribe from the data model. This is incorrect: WPF GUI objects do not disconnect event handlers when they are destroyed, because the overhead of doing so is significant. OK, so, what does that mean? Every single time you create one of these windows, it is stuck in memory until your data model is shutdown. If your data model lasts the lifetime of your program, as is common, that means every single window will stay in memory forever. This makes no sense, but once you realize that the GUI objects never disconnect their CollectionChanged event handlers, well, that's what happens.

This is not an issue for WPF's PropertyChanged handlers because the WPF framework creates and registers weak delegates itself (oblique reference here). It is only an issue for collections.

Secondary Problem

A second, unrelated issue with WPF is thread affinity. WPF GUI objects can only be used on their thread of creation. This can become an issue when, for example, you have a worker thread that updates a collection. The CollectionChanged notification then fires on the worker thread and you promptly receive a WPF exception from WPF's CollectionView GUI object stating that it can't be run from a non-GUI thread. The only fix for this is to Dispatcher marshal the call back to the GUI thread. However, the nature of multi-thread access to a shared [threadsafe] collection means that not all accesses are safe. In particular, if you remove objects from your collection or change them to different types on a worker thread, then a GUI thread can subsequently crash (due to a count mismatch or type mismatch). This is why the WPF team omitted automatic support to marshal these calls to the GUI thread (see question 6.3 here).

In NET 4.5, this has now been resolved by adding synchronization support so all GUI accesses of the object go through a lock object or user-supplied lock method. But I can't rely on NET 4.5 right now, so I have to roll my own solution as many others have done. The solution for this is presented here as well because it requires knowledge of the solution to the primary problem.

Potential Resolutions

There are only two ways to fix this:

1. Subscriber: Modify the WPF objects so they all disconnect their event handlers when the window is closed.

2. Event Provider: Modify ObservableCollection so it uses weak references somehow for all subscribers.

Unfortunately, we don't have the source to WPF and there's no word that the WPF team is going to address this anytime soon. Further, NET 4.5 adds support to resolve some instances of this problem using a variation of solution #2, so that appears to be Microsoft's direction for resolution. That brings us to solution #2. The NET framework supports a concept called a weak reference. This is a reference to an object that isn't considered a reference for garbage collection purposes. This is designed to let you hold a reference to an object that you need to use, but you don't want your reference to keep that object in memory. Weak references are designed for exactly this sort of problem.

To review, a callback in C# is a delegate object, implemented by System.Delegate. Delegate objects contain only two members: method and target. The method isn't an issue here since that's a reference to class type information that is already stuck in memory. There's only one instance of that anyway. So what we want to do is subclass System.Delegate to add a WeakReference member, use that instead of Target, and override Target to resolve the weak reference and then make the call. Conceptually, this is easy. However, we can't subclass System.Delegate, so we're stuck, right?

Specific Problem Statement

To fix this issue, we must meet the following requirements:

1. Convert a user-supplied delegate into a weak delegate, one that uses a weak reference to Target instead of a strong one.

2. Provide an ObservableCollection that uses weak delegates for CollectionChanged handlers

3. Install and remove handlers in the standard way, so this class is a drop in replacement.

This class should be a drop-in replacement for an existing ObservableCollection. Checking the class source, we see that it uses a virtual CollectionChanged event and calls a virtual OnCollectionChanged handler to raise the event, so our needs have been anticipated. That means meeting item #2 and #3 are straightforward. The real problem is #1, converting a delegate into a weak delegate.

Solution

Simple Weak Delegate

The very first solution that may occur to you is to simply keep a list of WeakReferences of delegates. In other words, it might seem easy to do this:

private List<WeakReference<NotifyCollectionChangedHandler>> actualHandlers;

public event NotifyCollectionChangedHandler CollectionChanged

add

actualHandlers.Add(new WeakReference(value))

remove

// Omitted for clarity, unimportant here

protected virtual void OnCollectionChanged( object sender, NotifyCollectionChangedEventArgs e)

foreach (var weakWrapper in actualHandlers)

{

NotifyCollectionChangedHandler actualHandler;

actualHandler = (actualHandler) weakWrapper.Target

if (actualHandler != null)

actualHandler.Invoke(sender, e);

}

However, this would be an immediate failure because the entire delegate will be cleaned up at the first GC because nothing effective references it. The only object referencing object is a WeakReference, so there is nothing holding the user's delegate in memory. So that won't work.

Slow Weak Delegate

Let's look into a key problem we have in solving this to better understand how to solve it. A key problem is that we can't override System.Delegate. But we need to add a member to System.Delegate to do this! So we can't change System.Delegate...Wait! Let's write our own delegate with our OWN target object. When our Invoke call is made, we'll be running in the context of our own object and we can access any state we need. We can then make the Invoke call as needed. This should solve it! Let's write it:

/// <summary> /// Weak delegate for a delegate following the standard EventArgs pattern: args are sender, EventArgs-descendant /// Works fully, but performance is bad since invocation is based on MethodBase.Invoke /// </summary> /// <typeparam name="T">An Event-Args derrived class</typeparam> public class WeakEventHandlerSlow<T> where T : EventArgs { private WeakReference targetReference; private MethodInfo methodToInvoke; private EventHandler<T> wrappedHandler; public WeakEventHandlerSlow( EventHandler<T> newHandlerToWrap ) { if (newHandlerToWrap.Target != null) targetReference = new WeakReference(newHandlerToWrap.Target); methodToInvoke = newHandlerToWrap.Method; wrappedHandler = InvokeWrappedHandler; } public void InvokeWrappedHandler( object sender, T eventArguments ) { // Is this an object member method? if (targetReference != null) { // Yes, resolve THIS and make the call, if THIS is still alive object targetObject = targetReference.Target; if (targetObject != null) methodToInvoke.Invoke(targetObject, new object[] { sender, eventArguments }); } else { // No, this is a static/anonymous method. Invoke without THIS. methodToInvoke.Invoke(null, new object[] { sender, eventArguments }); } } /// <summary> /// Casts constructor type to needed EventHandler[T] type to support easy syntax (event += new WeakEventHandlerSlow(userHandler)) /// </summary> /// <param name="weakWrappedHandler">The wrapped weak event handler to convert</param> /// <returns>A delegate that matches the signature of user handler that is being wrapped</returns> public static implicit operator EventHandler<T>(WeakEventHandlerSlow<T> weakWrappedHandler) { return weakWrappedHandler.wrappedHandler; } }

This solution works! We have our own object with a handler that meets NotifyCollectionChanged. We can then take apart the user's delegate, store the method and target separately, using a weak reference to the target. When our InvokeWrappedHandler is called, we simply call resolve Target and call the user's handler with it, if Target is still good. Now that we see the solution, it also doesn't look all that complicated, so maybe that's why we haven't heard much about this from the WPF team.

As it turns out, I'm working on a real-time data acquisition and graphing application, so we have to be very performance sensitive. CollectionChanged notifications are going to happen often in my app and servicing them quickly in the GUI will be important, so I did some performance tests to see how much slower this was than a normal user handler. I'm concerned about overhead of the call process, so my subscriber method is a trivial method that simply increments a variable and returns. I want to be comprehensive, so I've tested this with three different types of callbacks: a class instance method, a class static method, and a lambda method. For 1,000,000 calls, the results are as follows:

So my overhead is...200x, or 200,000%, if you like shockingly big numbers. The most important question to ask next is: Does this matter? This means it takes fractions of a fraction of a millisecond to fire the notification. Unless you're firing these notifications often or need to respond to them in the same picosend as the call, no, it's fine. Remember, the SLOW solution can fire 645,161 times per second, and it takes barely 2 HUNDRETHS of a MILLISECOND to fire. So before going any further, always ask yourself, is this good enough?

Fast Weak Delegate

My company is focused on accuracy and performance. Also, we will have hundreds of collections firing these events during real-time data acquisition. So for us, the answer is: yes, it does matter, make it faster. So how do we solve this? First, if you profile what the wrapper is doing, you'll find that all the slowness is in one place: methodToInvoke.Invoke. The overhead of wrapping the call, resolving the weak reference, and our small amount of logic are insignificant. It's all in Invoke. I learned a great deal researching this problem. First, this type of method invocation is one of the slowest in the NET framework. The following graph (borrowed from MSDN, here's the full article) illustrates the differences: