Thanks Pedro, I've seen what your describing in the docs - I'm looking at this via the profiler which is giving me feedback as to number of live instances, etc. Here's what I'm basing my statements on:. 1) I start up my app, which loads modules at runtime based upon user choice from a menu. 2) Module exectues Cairngorm Event/Command/Delegate to get array to populate a combo box. I'm passing a reference to the module's model in my Cairngorm event and the model is updated upon completion of the Command. 3) Combobox is bound (via MXML) to the model. 4) If I don't interact with the combobox, I can then logout and unload the module successfully. The profiler tells me there was previously 1 instance of the module and now there are zero instances. 5) If I make the combobox active (by interacting with it in any way), and then logout, the module remains in memory, with the profiler reporting one instance instead of zero. 6) If I then login again, the Profiler reports 2 active instances of the module. Note that any model objects are duplicated as well. For example, if my list of suppliers (used to popuate my combobox) (a strongly typed AS class) was previously 64, the profiler now reports there are 128 instances. There's my behavior. When my UI object (in this case ComboBox), becomes active, the binding becomes active and then the module will not unload, even if I set the modules model to null before attempting to unload. It would appear that I need to invalidate all outstanding bindings to any data object before the module will fully unload. This would seem to indicate that MXML binding (via curly braces) isn't going to allow this. Jeff
-----Original Message----- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Pedro Sena Sent: Thursday, April 23, 2009 8:43 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Unloading Modules - Binding is the Enemy? 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 <mailto: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 */