Memory leaks 101: Objects anchored by event generators

re: Memory leaks 101: Objects anchored by event generators

barrkel — Wed, 10 Jan 2007 01:40:37 GMT

I still think this would be better solved with a weak delegate mechanism though.

re: Memory leaks 101: Objects anchored by event generators

Jon Arild Tørresdal — Wed, 10 Jan 2007 03:18:28 GMT

I've commented your post here http://blog.torresdal.net/PermaLink,guid,e4b6d502-6747-47cd-9fb7-bfc00811f16c.aspx

re: Memory leaks 101: Objects anchored by event generators

nzeeman — Wed, 10 Jan 2007 09:42:10 GMT

Can anybody tell us what was the reasoning for the design behind the strong reference model used in events in the first place?

re: Memory leaks 101: Objects anchored by event generators

Ben — Wed, 10 Jan 2007 18:19:07 GMT

[quote]Can anybody tell us what was the reasoning for the design behind the strong reference model used in events in the first place?[/quote]

I don't think there was ever a direct choice, whether the event model would be strong or weak references. Rather the event model uses delegates, and delegates use strong references.

Most use cases for delegates other than event subscription require strong references (unless you'd prefer the GC cleanup all your work items leaving the thread pool to execute dangling delegates). In fact, the strong reference is directly exposed as the Delegate.Target property. Correct me if I'm wrong, but anonymous delegates w/binding to local parameters is fundamentally incompatible with weakly referenced delegates.

re: Memory leaks 101: Objects anchored by event generators

Ben — Wed, 10 Jan 2007 18:26:07 GMT

Then again, if generics supported inheritance from a generic parameter, it would be almost trivial to make a flexible WeakDelegate wrapper. As it is, I suspect a little lightweight codegen could do the trick, letting the compiler do generic argument deduction to give you the exact delegate type, which you can reflect against to determine the number and types of arguments.

re: Memory leaks 101: Objects anchored by event generators

ricom — Thu, 11 Jan 2007 01:48:24 GMT

You're right that weak references would make anonymous delegates problematic.

re: Memory leaks 101: Objects anchored by event generators

Tess — Thu, 11 Jan 2007 12:09:41 GMT

Here are two debugging walkthroughs for finding memory leaks caused by attaching instance eventhandlers to cached and static objects

http://blogs.msdn.com/tess/archive/2006/01/23/516139.aspx

http://blogs.msdn.com/tess/archive/2006/11/27/asp-net-crash-bad-cacheitemremovedcallback-part-ii.aspx

Interesting Finds: January 13, 2007 Part B

Jason Haley — Sat, 13 Jan 2007 21:59:37 GMT

re: Memory leaks 101: Objects anchored by event generators

Darren Oakey — Fri, 19 Jan 2007 15:17:56 GMT

This issue bites us every day. We've tried to make our own weak reference methods - even dynamically creating the IL for the callbacks - but we can't get it anywhere near as fast as the event system, which is important to us :(

But basically, almost every bit of code in our system is asynchronous, so has to be hooked up using some sort of event or callback - it wouldn't make sense to completely invert the object hierarchy, so it's almost as if we have no GC - we are back to the bad old world where we must explicitly destruct (dispose) every single object at the right time - and sometimes miss one.. even a single mistake can lock a huge tree in memory.

The thing is, given that you can also use a callback or handler interface, which we do for everything that absolutely has to be listened to, I don't think there has ever been a time where I have used an event and would actually want that to lock the recipient class into memory...

I think mostly when we use an event we are thinking decoupling - we are thinking A references B, but B doesn't reference A.

If there was any way to change the current event system over to weak referenced, we'd be soooo happy... but even a second event paradigm would be incredibly useful!

Please? :)

Actually, thinking of it- there are several sort of ways of doing a weak reference based event on the net - none are super efficient, but what would be useful would be if some MS person (like you :)) - went through and created the "ideal" weak referenced event pattern. We could all start using it now, and it could just nicely flow into Orcas.