Object garbage collection of events

[Jay Dee]

Object garbage collection of events

I can not help wondering how the garbage collection system handles
events.

If I release all references to an object that has a void that an event
somewhere is using I then have no access to the class holding the void
so it should be garbage collected.

But if an event holds a reference to a void of the class that I have
no reference to douse the class stay in memory because something
refers to it or is that reference removed from the event.

Basically do I need to remove all event calls before releasing an
object or are they removed automatically.

I hope someone understands what I mean.

This code thaw incomplete hopefully helps explain what I mean.

Thank you all

Jay Dee

<code>

static class Program
{
static void Main()
{
Form1 form = new Form1();
form.myClass = new MyClass();
form.MyEvent += new EventHandler(form.myClass.MyEventCall);
form.myClass = null;
Application.Run(form);
}
}

public class Form1 : System.Windows.Forms.Form
{
MyClass myClass;

public event System.EventHandler MyEvent;

public void OnMyEvent(EventArgs e)
{
if (this.MyEvent != null)
{
this.MyEvent(this, e);
}
}
}

public class MyClass
{
public void MyEventCall(object sender, EventArgs e)
{
// do somthing.
}
}

</code>

 

[Scott M.]

Events do not hold refences to objects, nor does garbage collection relate
to an object's events.

An object is elligible for garbage collection when it has no "applicattion
roots", that is it is no longer reachable from any code paths in the
application. Hooking an object up to an event handler (registering
delegates to handle event notifications for the object) do not count as an
application root. Only object variables count.

-Scott

 

[Peter Morris]

Do this in an MdiChild form
MdiParent.Activated += SomeMethod;

Then dispose of that MdiChild form. The form will not be collected until
the main form closes.



Pete

 

[raylopez99]

On Jul 25, 9:07 pm, "Peter Duniho" <[email protected]>
wrote:

I wonder: how do you manually collect a static object/variable?
Specifically, a static class. In another thread I created a static
class for a subform/child window that works fine but 'hangs around',
and when the subform/child window is reopened, the static class is
still there, and creates problems since it's part of an Event/Delegate
model.

RL

 

[Göran Andersson]

On Jul 25, 9:07 pm, "Peter Duniho" <[email protected]>
wrote:

I wonder: how do you manually collect a static object/variable?
Specifically, a static class. In another thread I created a static
class for a subform/child window that works fine but 'hangs around',
and when the subform/child window is reopened, the static class is
still there, and creates problems since it's part of an Event/Delegate
model.

RL

The object isn't static, it's only the reference to the object that is
static. The object is allocated on the heap just like any other object,
and if you remove the reference from the static variable (e.g. setting
it to null), the object can be garbage collected.

 

[olduncleamos]

Events do not hold refences to objects, nor does garbage collection relate
to an object's events.

An object is elligible for garbage collection when it has no "applicattion
roots", that is it is no longer reachable from any code paths in the
application.  Hooking an object up to an event handler (registering
delegates to handle event notifications for the object) do not count as an
application root.  Only object variables count.

-Scott

This misunderstanding could be costly...

http://www.codeproject.com/KB/showcase/IfOnlyWedUsedANTSProfiler.aspx

 

[Jay Dee]

I thank you all for your valuable responses.

Sorry for miss using the word “void” I think that I mean “method”.

I am still slightly confused as there seems to be two different views
here and I don’t know witch is correct.

Would I be correct in saying that in my example above a call to
“form.MyEvent” will not call the method “MyEventCall” as I no longer
have a valid reference to that method.

Or is that method still valid because the event its self still refers
to it.

Thank you all.

Jay Dee

 

[Jay Dee]

Would I be correct in saying that in my example above a call to

No, that would be incorrect.


Yes.  When you subscribe to the event, a delegate is created ("new  
EventHandler(...)"), and that delegate references the instance of MyClass 
used to create the delegate.  As long as the event itself is reachable,so  
too will be anything it references, and anything that it references  
references, and so on.

   Just because _some_ reference to that instance of MyClass no longer  
exists, that doesn't make the instance go away.  It's only when that  
instance of MyClass becomes "unreachable" that the instance may be garbage  
collected.  An instance is "reachable" if a reference to it is stored in a  
root (such as a static field or local variable), or a reference to it is  
stored in a data structure that is itself "reachable" (so there's a  
recursive aspect to the definition of "reachable", as noted above).

So in your example, as long as the Form1 instance is reachable, so too is 
any class instance referenced in a delegate subscribed to an even in the  
Form1 instance.

Basically: the garbage collector doesn't go around invalidating  
references.  Instead, it collects objects only when you can no longer get  
at them.

Pete

Thank you. That was a well written response.

 

[Jeff Louie]

Basically do I need to remove all event calls before releasing an
object or are they removed automatically.<<

Jay... As Peter suggest, using events can lead to the "lapsed listener"
conumdrum:

http://weblogs.asp.net/fmarguerie/archive/2004/07/27/198489.aspx

One solution is the weak event manager:

http://msdn.microsoft.com/en-us/library/system.windows.weakeventmanager.
aspx

Another alternative would be supplier driven registration of listeners.

Regards,
Jeff