1

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?

Community
  • 1
  • 1
Haozhun
  • 6,331
  • 3
  • 29
  • 50
  • 3
    The accepted answer for (1) has 53 upvotes. How likely is it that it is wrong? (especially given the calibre of the people that frequent this site). – Mitch Wheat Dec 13 '11 at 03:40
  • @MitchWheat I totally agree with you about the two people answered those question. But how could Silverlight UI's subscription to PropertyChanged events cease to exist if and only if garbage collection happens? – Haozhun Dec 13 '11 at 04:25
  • To those who are trying to close this question. Read my question before trying to close it! And leave a comment to justify your decision. – Haozhun Dec 13 '11 at 04:26

1 Answers1

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.

Adam Robinson
  • 182,639
  • 35
  • 285
  • 343
  • 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](http://stackoverflow.com/questions/4022461/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? – Haozhun Dec 13 '11 at 04:31
  • 1
    @Gene: It isn't just common sense, it's fact. I've added information to my answer that deals with the specifics of Xaml bindings, but none of the answers that you have presented are in contradiction. – Adam Robinson Dec 13 '11 at 13:23