Well if we're talking about modules... If you're loading the same module over and over again that might be the problem... A while back I had to modify ModuleLoader and while I was in the code I seem to remember it has some caching built into it. So it may be possible that ModuleLoader is holding on to a reference of a module.
I got around the caching issue when loading the same module over and over again by appending a random number to the loaded module. (ex: myModule.swf?uid=123456789). The ModuleLoader stuff I was working on was back in 2.0.1... so it might be very different now. Hope this helps. On Thu, Mar 5, 2009 at 10:08 AM, claudiu ursica <the_bran...@yahoo.com>wrote: > I read this too, however when watching in profiler the gc runs a removes > a set of the instances, the thing that bothers me is that after first > load/unload the memory looks like the module is there. After the second load > looks like 2 modules are load I get duplicate instances ... After the second > unload and forcing running gc a few times from profilet a set of instances > is collected, but i still have the memory looking like I have one module in > there. I don't get it how come that on set of instances are removed and one > is there for good... It seems there is no way to see if my cleaning is > actually hapenning ... One could say is happening since the second, third, > forth load/unload are actually cleaned but there's still a set of instances > in the memory ... > > > > ------------------------------ > *From:* Nate Beck <n...@tldstudio.com> > *To:* flexcoders@yahoogroups.com > *Sent:* Thursday, March 5, 2009 7:55:01 PM > *Subject:* Re: [flexcoders] Module unload GC > > Garbage Collection happens when it needs to happen. You have no control > over it. This is from Grant Skinner's blog: > > *Deferred GC and Indeterminacy* > A *very* important thing to understand about the Garbage Collector in FP9 > is that it's operations are deferred. Your objects will not be removed > immediately when all active references are deleted, instead they will be > removed at some indeterminate time in the future (from a developer > standpoint). The GC uses a set of heuristics that look at RAM allocation > and the size of the memory stack (among other things) to determine when to > run. As a developer, you must accept that fact that you will have no way of > knowing when (or even if) your inactive objects will get deallocated. You > must also be aware that inactive objects will continue to execute > indefinitely (until the GC deallocates it), so code will keep running (ex. > enterFrames) , sounds will keep playing, loads will keep happening, events > will keep firing, etc. > > It's very important to remember that you have no control over when your > objects will be deallocated, so you must make them as inert as possible when > you are finished with them. Strategies to manage this will be the focus for > a future article. > > > On Thu, Mar 5, 2009 at 3:58 AM, Claudiu Ursica <the_braniak@ > yahoo.com<the_bran...@yahoo.com> > > wrote: > >> Hi, >> I'm using a module in my app. And I'm profiling the app to see if >> unloading cleans after itself... The thing is the first time I unload >> nothing happens all the instances are still there in the Profiler. Now if I >> load the module again, the memory increases and the insatnces no. doubles. >> However when I unload the second time, the cleaning happens and I'm getting >> the memory and instances no from before the load. Is this normal, it looks >> to me like I'm having a module in there all the time after the first load... >> I'm pretty sure I do my internal cleaning OK before unloading the module, >> fact proved by the second, third forth load/unload .... >> >> Has anyone bumped into this? >> How reliable is the Profiler on this? >> >> Any input is appreciated. >> >> TIA, >> Claudiu >> >> > > > -- > > Cheers, > Nate > ------------ --------- --------- --------- - > http://blog. natebeck. net <http://blog.natebeck.net> > > > > > -- Cheers, Nate ---------------------------------------- http://blog.natebeck.net
