On 2010-03-24, at 18:25, Max Carlson wrote:
>> Issues:
>>
>> 1) LZNode#2080
>>> //remove __LZconstraintdelegates
>>> // We have to do this to remove LzDataAttrBinds
>>
>> I don't follow. It seems to me that in LzNode/dataBindAttribute, the
>> LzDataAttrBind object needs to go on __LZconstraintDelegates, so it can be
>> applied/unapplied by LzState. But LzDataAttrBind's constructor should
>> register the binding on __delegates so that it can be auto-cleaned when the
>> node it is binding is destroyed. We really want to separate these two tasks
>> so future generations don't have to work this out again. Then you can truly
>> just let __LZconstraintdelegates drop on the floor in LzNode/destroy.
>>
>
> It turns out removing this has causes Flash10 to show a memory leak -
> removing constraint delegates explicitly helps a lot... I wonder why?
It should never be the case that there is a foreign delegate on
__LZconstraintdelegates that is not already on __delegates. Perhaps you could
put some debug code in to see if that is every happening and figure out why?
> Is is the closure in LzDelegate#register?
>
> if ($as3) {
> var a:Array = new Array(m.length);
> this.m = function (ignore:*) :* { return m.apply(this, a); }
> }
That should only get called if your handler doesn't take the required 1
argument. You would be getting debug warnings if that was being invoked.
> If this is the case, perhaps we need to track all delegates, at least in
> as3...
How exactly are you measuring these leaks? It's ok for a delegate that
connects a node to itself to stick around at node destroy time, because they
will get collected when the node itself is (eventually) collected.
