Comments on: Moment of Weakness: Weak Event Listeners Can Be Dangerous

By: Learning Flex – Lesson 26, The Basics of Memory Management and Performance « M@ Blog

Mon, 08 Mar 2010 01:48:32 +0000

[...] would be eligible for garbage collection. Here’s a post with more on weak references and here’s an opinion on when they shouldn’t be [...]

By: Rein

Rein — Fri, 03 Apr 2009 10:14:02 +0000

Thanks so, so much for this article.

I’ve spent 2 and a half day trying to figure something similar out. Turned out to just set one boolean to false would do the trick ;)

Thanks!

By: joe

joe — Wed, 16 Jan 2008 00:58:46 +0000

One other note: I continue to be careful with weak refs because problems with premature GCs show up so unreliably and unreproducibly that they are hard to catch in testing. My approach is to start with strong refs, and then weaken them until memory leaks disappear (hooray for the Profiler). A memory leak is deterministic: it’s bound to show up if you look for it. A premature GC might or might not happen.

By: joe

joe — Wed, 16 Jan 2008 00:55:09 +0000

Well, this continues to be a hot topic. I am presently tracking down a bunch of memory leaks in an app I wrote with the help of the Flex Builder Profiler, and many of them are amenable to being solved via weak references. But I also have run into a number of situations in which objects using the Mediator design pattern are prematurely GCed if all their listener references were weak. Obviously an object such as a Mediator (whose only role is to listen to events from other objects) is not going to stick around unless there is at least one strong ref. So I continue to maintain that weak refs, while an essential tool, are not a panacea!

By: David Dumke

David Dumke — Wed, 16 Jan 2008 00:24:07 +0000

As Robert mentioned if you use strong references sometimes the object gets lost and you can never GC it. This happened to me running a flex app that dispatched many events as part of a streaming bus between a server and the app. As well as created and destroyed many widgets as part of a UI. The problems because the app needs to run for a long time. The strong references somehow prevented the widgets from GC’ing or barring that kept the even listeners around. The end result was a totally bogged down flash app that ran 100% faster once all the listeners were replaced with weak versions. That is all except those that would always need to be active.

So in short this is a godsend and I don’t use strong references unless absolutely necessary. I can see how this will cause trouble in terms of the patterns described above but I think it worth mentioning that advising to use strong references whenever possible is not necessarily the right answer here.

My understanding of AS3 is still limited but from what I can tell I would suggest using weak references whenever possible, and be aware of the pitfalls. The performance boost was amazing once I started using them.

By: Robert Penner

Robert Penner — Wed, 21 Nov 2007 20:27:37 +0000

> Weak event listeners are great if the client that obtains them can be expected to maintain a reference to them for as long as they need live.

If you are not maintaining a reference to an object and thereby directly controlling how long it lives, then you are headed for one of two problems:

1) If you use a weak listener reference, the object will be garbage collected at a random time, as you describe.

2) If you DON’T use a weak listener reference, you’re setting yourself up for a memory leak. If the object falls out of scope and you no longer have a named reference to it, that means you have no way to release it to the garbage collector. There will be an unnamed reference to the object in a listeners array somewhere that will exist forever. That is, unless you have some scheme where the object removes itself as a listener. But if the object fails to do that, it will stick around.

By: Weak References: Utilisation potentiellement dangereuse. | Matsiya

Weak References: Utilisation potentiellement dangereuse. | Matsiya — Sat, 08 Sep 2007 15:50:28 +0000

[...] L’article sur le blog de Joe Berkovitz : Moment of Weakness: Weak Event Listeners Can Be Dangerous [...]

By: Paul Rangel

Paul Rangel — Sat, 11 Aug 2007 22:15:02 +0000

Awesome and thanks again Joe. I owe you a pint at the next event!

paul

By: joe

joe — Sat, 11 Aug 2007 19:10:42 +0000

Paul, I don’t see any problems off hand in the pattern. There is nothing in the pattern that says weak listeners need to be used, and an Operation is a disposable object, so attaching strong listeners to it should be safe (they can be harvested once the Operation itself is GCed). I try to avoid weak listeners anywhere unless there’s some ironclad argument for them.

Did I miss something? Let me know if you see a specific case.

As far as 360Flex in Seattle goes, my Allurent colleague Jim Echmalian (http://www.ech.net/blog/) will be speaking there about “Practical Patterns in Flex” which picks up where MVCS leaves off. I highly, highly recommend seeing his talk!

–Joe

By: Paul Rangel

Paul Rangel — Sat, 11 Aug 2007 16:27:54 +0000

We are avid users of the MVCS pattern you described on the Adobe website and I swear this has happened to us on occasion. Seems that the operation classes in the pattern would be victim. Do you see any potential pitfalls in the MVCS pattern for this bug?

Also, I was looking forward to your talk at Flex360 you going to be on the West Coast in the future? Thanks for the great tips and see ya at the next Flex event.

-paul