loadercore required with root not always GC'd [SOLVED]

[bertusvandalen]

.... seems because they can still serve as an object key in the static _rootLookup dictionary

 

putting this on end of the _dump function seems to solve the problem, for now (...?)

 

if(this.vars.requireWithRoot is DisplayObject && scrubLevel == 3)

{

var existsAsRootLookupIndex:Boolean = (_rootLookup[this.vars.requireWithRoot] != undefined);

if(existsAsRootLookupIndex)

{

delete _rootLookup[this.vars.requireWithRoot];

}

}

 

so would this change cause any other problems? which?

 

would there be a better solution to the problem?

 

thanks, kind regards,

 

bertus

[GreenSock]

Yeah, that would cause problems because more than one loader might have the same requireWithRoot. With your code, if you dispose() one of the loaders, it would remove the swf's root from the _rootLookup (it shouldn't because there's still another loader with that root).

 

Are you disposing the SWFLoader itself? That should clean up after itself, although I believe one line needed to be added to its _dump() method to handle the _rootLookup - would you mind trying the attached updated version of SWFLoader and letting me know if that solves things for you?

[bertusvandalen]

A very big thank you, this solved the problem indeed.

 

The goal is to have a dependency tree composed of loadermaxes to enable modular development, so there's a bunch of recursive functions iterating via the getChildren method, removing branches deepest first while removing pureMVC cores when applicable and replacing them by other modules with branches when applicable. Without stuffing memory

 

We'll see how far we can take it... thanks again

[GreenSock]

Great. The new version is up on the main site now.

[bertusvandalen]

Here's the SWFLoader subclass adding some functionality that I was missing. Hopefully it will not harm anyone especially me....

 

update: SWFLoaderBranch.zip