Provide simple syntax to create a weak-referenced eventhandler

[dotMorten]

The by far most common memory leak people introduce in .NET apps are caused by event handlers added to longer-lived objects. For instance an event on a static instance, or on an instance who's lifetime is the entire app lifetime (like app view model or app settings).
Listening for events on this from a shorter-lived object, makes this short-lived object hang around in memory until the app stops running. A common scenario is the INotifyCollectionChanged event listened to by a XAML control, with data coming from a collection provided by some app state. This will cause a very memory-consuming object like a UIElement to stay around in memory until the app closes. The recommended pattern to avoid this is by using WeakReference preferable wrapped in an event manager / event proxy class. However this can be quite a lot of code to write, and the implementation is not straight forward, and will still cause the small proxy hang around at least until the event fires again (if it ever does).

It would be much simpler if a syntax alternative to "+=" would denote "weak". For example:

    staticInstance.Data.CollectionChanged += MyChangedHandler; //not weak event reference
    staticInstance.Data.CollectionChanged +~ MyChangedHandler; //weak event reference 

I'm not saying '+~' should actually be the syntax - just that we have something as simple as this to solve a very common scenario.

Uservoice suggestion for voting: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/7019993-provide-simple-syntax-to-create-a-weak-referenced

[svick]

What exactly would +~ do? Create that proxy class that doesn't completely avoid the memory leak? Or do you want some kind of "weak delegate" supported by the runtime? Or something else?

[sharwell]

@svick You can completely avoid the memory leak by using a ConditionalWeakTable to bind the lifetime of the delegate to the lifetime of the listener instead of the lifetime of the event source. Obviously this isn't a complete implementation explanation, but it does show that support for this concept exists within the current runtime.

[dotMorten]

@sharwell Thank you for the ConditionalWeakTable option. However it doesn't change the fact that this is a common problem that there should be a simple syntax for accomplishing.
@svick I'm fine with using a proxy, if using the method @sharwell proposes. That would mean it could be backwards compatible for framework, and be a compiler-only thing. Either way the goal of this proposal is to make it simple to create weak event handlers, so people can easier write good code that doesn't accidentally hang on to objects for too long.

[sharwell]

@dotMorten We are on the same page regarding the challenges of this functionality, which is essential for many kinds of applications.

A nuance of the +~ you describe is the requirement that it only be used in an instance member of a reference type, and it can only bind the weak reference to this. I imagine this could be very confusing for some users, and limiting for others. For example, suppose your application had a text window DiagnosticLog which could be opened by a user, and contained a DiagnosticLog.WriteLine method. A user might want to do this:

static void SomeUtilityMethod(DiagnosticLog log)
{
  AppDomain.AssemblyLoad +~ (sender, e) => log.WriteLine("Assembly Loaded");
}

How would you support attaching the weak event to log instead of this?

Other Approaches

The closest syntax you can have right now is the following:

environmentData.CollectionChanged += AsWeak<TEventArgs>(this, HandleCollectionChanged);

Where AsWeak is a method with the following signature:

static EventHandler<TEventArgs> AsWeak<TEventArgs>(object owner, EventHandler<TEventArgs> handler);

It would be safer to have a generic owner in order to use a generic type constraint and avoid boxing:

static EventHandler<TEventArgs> AsWeak<T, TEventArgs>(T owner, EventHandler<TEventArgs> handler)
    where T : class

However, this would increase the verbosity of usage:

environmentData.CollectionChanged += AsWeak<ThisType, TEventArgs>(this, HandleCollectionChanged);

Aside from your syntax, the use of weak event handlers would be simplified by improving the ability of the compiler to resolve the generic arguments for a call of this form.

[dotMorten]

@sharwell Wrt to your example

static void SomeUtilityMethod(DiagnosticLog log)
{
  AppDomain.AssemblyLoad +~ (sender, e) => log.WriteLine("Assembly Loaded");
}

You are declaring an anonymous delegate here, which goes out of scope immediately. This means it's up for garbage collection right away. In this scenario you would never want to do this anonymously. I can see how this might be confusing, but IMHO is very much expected and wanted behavior. Instead this would make more sense:

static void SomeUtilityMethod(DiagnosticLog log)
{
  EventHandler handler = (sender, e) => log.WriteLine("Assembly Loaded"); //pin handler to local scope
  AppDomain.AssemblyLoad +~ handler;
  //perform some assembly loading
  //

   //No need to remember to do this because of weak event:  AppDomain.AssemblyLoad -= handler;    
} //'handler' out of scope and unhooks from event.

[matwilko]

@dotMorten That may not hold up based on what optimizations the compiler might quite correctly perform.

If you don't use the handler local again after those initial two lines, the compiler has every reason to consider it "dead" because you never access it again, and so a valid optimization might be to simply reuse that local (in CIL terms) again if you define another EventHandler local further down the method.

Because of this, your assertion that you're "pinning" the handler in the local isn't true under all conditions, and it can still become immediately eligible for garbage collection.

[sharwell]

@dotMorten In the example I gave, the life of the EventHandler would be bound to the life of the receiver log, so it wouldn't prevent log from getting garbage collected but it would stay alive as long as log is otherwise alive.

[JohnnyBravo75]

This is one of my top wishes, because memory leak through event handlers are very common.

And the other way around? I declare an event as weak, not the subscribers, so the subscribers can only listen as long as the event is alive and fired?

public weak event EventHandler<CustomEventArgs> RaiseCustomEvent;

[svick]

@JohnnyBravo75 How is that different from normal events? An event is basically just a list of delegates. If the object that holds the list gets GCed, so will the delegates (and potentially also the subscribers).

[dotMorten]

@svick it's not different but the reference back often surprises people and causes stuff to "leak". And example is listening to events on static instances. Your class listening will stay in memory for the entire duration of the app. Quite often this isn't intended. Normally when you hold a reference to a static object its fine - your object can still be GC'ed. But because the event handler "points the other direction" this means the longer lived object unintentionally holds on to the shorter lived.
Another case is a UI control listening for property changes to a model object. The UI element is often short lived (especially for page navigating apps) but because the model data often stays alive in the lifetime of the app, if could be holding on to a lot of very memory expensive UI elements. There's a way to write the code for this but it's ugly, lot of code and thus also error prone. And more importantly developers never bother. Let's make it easy so they will.

[svick]

@dotMorten Yes, I understand that and I think that some way to fix that should be in the language.

My question was specifically aimed at @JohnnyBravo75's comment about his version of weak event where "the subscribers can only listen as long as the event is alive". Because that's how normal events already work, subscribers don't keep the object with event alive.

[whoisj]

An ideal way to manage this kind of thing would be to make WeakReference cheaper and easier to utilize. Effectively a way to keep a handle on an object until that object is no longer valid without the curse of keeping the object valid long beyond its intended use simply because you have a handle on it.

This is a bit of a crusade of mine because there's is no explicit way to free memory in C# and nearly all memory leaks are caused by people not realizing that they're keeping memory locked up long after they no longer need it (event handlers being a huge source of problems currently).

A weak reference should not impact GC logic, but should be set to null when the GC cleans up the memory associated with the allocation.

private weak object m_weak;

void Method(object solidObj)
{
    m_weak = solidObj; // the reference won't prevent garbage collection
}

If the community feels that call site markup is necessary to help explain / make more explicit / etc the assignment of weak references, then the ~ assignment, or similar, makes sense. Perhaps a specialized cast to weak (example below) makes more sense?

private weak object m_weak;

void Method(object solidObj)
{
    m_weak = weak(solidObj); // the reference won't prevent garbage collection
}