Hi Jeff, The fact that you unload a module does not mean that it will be garbage collected(the memory won't be released as soon as you unload your module). Unload the module makes it available for garbage collection.
As far as I know, the module 'garbage' will be collected by the GC when necessary, so don't think that unload a module means free memory in the exactly same moment. I'm supposing that you are testing in your development machine(probably a good machine) so I suggest you to test it in a limited machine to see if this memory is released when it is *necessary* , that is the point. HTH, Pedro Sena On Thu, Apr 23, 2009 at 9:09 AM, Battershall, Jeff < [email protected]> wrote: > > > In testing via the Profiler, binding UI objects in a module to a model > (even if local to the module) appears to be causing a module's failure > to unload. This happens as soon as the UI component becomes active. In > fact, even if the source object (data provider) is set to null, the > binding persists and will prevent a module from unloading. Does this > issue have to be such a PITA? It appears that using curly braces for > binding in MXML can create Modules that won't unload. > > In FP 10, the Loader class has the new unloadAndStop() method. Would be > extremely handy to have something similar for Modules. Basically you > want to remove all listeners to a model and then unload the module. > > Seeking enlightenment - anyone got any? > > Jeff Battershall > Application Architect > Dow Jones Indexes > [email protected] <jeff.battershall%40dowjones.com> > (609) 520-5637 (p) > (484) 477-9900 (c) > > -- /** * Pedro Sena * Systems Architect * Sun Certified Java Programmer * Sun Certified Web Component Developer */
