Jeff, Calling GC programmatically does not mean that it will be executed.
Like java, the GC in flex is not under programmer's control. You may call it, but it won't be executed if it is not necessary. "Clicking the Run Garbage Collector button does not guarantee that all objects that are eligible for garbage collection will be garbage collected. Garbage collection is typically triggered by the allocation of memory for new resources." http://livedocs.adobe.com/flex/3/html/help.html?content=profiler_6.html Regards, Pedro Sena On Thu, Apr 23, 2009 at 9:34 AM, Battershall, Jeff < jeff.battersh...@dowjones.com> wrote: > > > Pedro, > > I've been running the GC immediately after unload - programmatically. The > module instance is released immediately if binding is inactive. The moment > binding becomes active to a UI element of the Module, the instance will not > be released. I was thinking that having the model object I'm binding to be > local to the module would address the behavior, but sadly it does not appear > to work. > > Jeff > > -----Original Message----- > *From:* flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] *On > Behalf Of *Pedro Sena > *Sent:* Thursday, April 23, 2009 8:26 AM > *To:* flexcoders@yahoogroups.com > *Subject:* Re: [flexcoders] Unloading Modules - Binding is the Enemy? > > 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 < > jeff.battersh...@dowjones.com> 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 >> jeff.battersh...@dowjones.com <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 > */ > > > -- /** * Pedro Sena * Systems Architect * Sun Certified Java Programmer * Sun Certified Web Component Developer */
