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: [email protected]
[mailto:[email protected]] On Behalf Of Pedro Sena
Sent: Thursday, April 23, 2009 8:26 AM
To: [email protected]
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
<[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]
<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
*/