I'm building some stuff with a serious potential to leak memory (but it's hella cool, watch this space). Specifically, dealing with binding to and from objects without keeping hard references to them, which is easier said than done! I've been going through the source code to the binding system, and all bindings eventually come down to ChangeWatcher.watch().

1. When you call watch(), you get returned the first of a chain of watchers, one for every host in the chain.
2. Every watcher in the chain with a non-null host has a hard-reference from the host object to itself.
3. Every watcher has a hard-ref to the handler function.

This of course leads to the fact that if you ever throw away your watcher reference before calling unWatch(), you're stuck with a zombie reference from the root of your chain to your handler function. Which means in turn that the host object is hard-referenced to anything within the handler function's scope. If the root of your chain happens to be Application, or anything else that lives the life of your app, you're almost certainly leaking memory.

I'd love to be wrong about my conclusions, but I don't think I am. I'll have to create a test some time over the weekend to prove it though, so I can file a bug (and a fix) with Adobe.

So in conclusion: Be awfully careful what you're putting in the handler function for any hand-created ChangeWatcher, or using BindingUtils!

Note that I don't think it's a problem for MXML bindings: Off the top of my head, if the root host of a binding chain defined in MXML is "A" then the handler function is generated as a member function of "A".