Question

I read Silverlight UI not unsubscribing from PropertyChanged events just now. It was exactly the question I’m having. I tried the experiment proposed by in the answer. And the answer is correct, they are collected upon explicit GC.

However, This result in two more questions:

1. This seems to be contradicting to these two threads on stackoverflow about Event Handler and GC: 1, 2. Are they wrong?
2. How is this implemented? I recall there’s something called weak reference in Java. Is it something related?

---

Here is some clarification of the question:

The eligibity to GC only when publisher cease to exist is common sense. But that common sense contradicts with the experiment in the answer of Silverlight UI not unsubscribing from PropertyChanged events, which proves Silverlight UI’s subscription to PropertyChanged events cease to exist if and only if garbage collection happens. I believe more in facts than common sense. But how could that fact be explained? weakref?

Answer 1

The answers to the two linked questions are not in contradiction; because an event subscription is a delegate to an instance method, the event publisher maintains an indirect reference to the subscriber, so the subscriber will not be eligible for collection until the publisher is eligible for collection. The second linked answer simply means that the garbage collector is smart enough to handle circular references (since the GC operates on the idea of reachability from a “GC Root” rather than simple reference counting).

If what you’re asking about is how XAML-based environments like Silverlight or WPF can have the UI elements garbage collected while they’re still bound to nonvisual elements, the answer lies in how XAML binding works.

At the risk of oversimplifying what is actually a very complex system (the whole of XAML binding), XAML binding does use the WeakReference type on its binding source to allow garbage collection of that object.