Modules will unload when there are no longer any references to the classes or objects in a module. There is a cache, but it uses weak references and will release the module when using the gc button in the profiler. The browser caches module SWFs but that won't affect this issue. Nate's solution sounded like the solution to the problem where you update a module on the server and want to load the new one.
If a module brings in a component that hasn't been loaded before, usually it brings in a CSSStyleDeclaration for it as well which gets registered with the central StyleManager and pins the module. You can check the id in the id column to see if the module that is pinned is the first one loaded. Alex Harui Flex SDK Developer Adobe Systems Inc.<http://www.adobe.com/> Blog: http://blogs.adobe.com/aharui From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of claudiu ursica Sent: Thursday, March 05, 2009 10:26 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Module unload GC I'll try that first thing in the morning... For now I'm loading the same module, but in the future there will be more modules, however since we only have one now and still working on it we have to test with one module... The thing I fear the most if that the same thing will happen for different modules, and then I'll have a serious memory leak. The modules will be quite complex with lots of functionality and animations (diffren games loaded on the same shell), that's why cleaning is so important... I was going to duplicate the module into another project to see if that still happens... Right now I'm nullifying manually the url of the module when unloading but whi knows what happens behind the scenes... ________________________________ From: Nate Beck <n...@tldstudio.com> To: flexcoders@yahoogroups.com Sent: Thursday, March 5, 2009 8:16:52 PM Subject: Re: [flexcoders] Module unload GC 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_braniak@ yahoo.com<mailto: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<mailto:n...@tldstudio.com>> To: flexcod...@yahoogro ups.com<mailto: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<mailto: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<http://blog.natebeck.net>
