RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Hang on, now I'm confused...
Does this code result in a weak reference binding?
mx:DataGrid id = uploadFromFoo
width = 100%
height = 100%
dataProvider = {
CairngormNameChangedToProtectTheInnocentModel.getInstance().uploadsFromF
oo }
allowMultipleSelection = false
change = viewHelper.uploadSelectionChange()
editable = false
I was always led to believe it wouldn't.
Gregor Kiddie
Senior Developer
INPS
Tel: 01382 564343
Registered address: The Bread Factory, 1a Broughton Street, London SW8
3QJ
Registered Number: 1788577
Registered in the UK
Visit our Internet Web site at www.inps.co.uk
blocked::http://www.inps.co.uk/
The information in this internet email is confidential and is intended
solely for the addressee. Access, copying or re-use of information in it
by anyone else is not authorised. Any views or opinions presented are
solely those of the author and do not necessarily represent those of
INPS or any of its affiliates. If you are not the intended recipient
please contact is.helpd...@inps.co.uk
From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On
Behalf Of Alex Harui
Sent: 28 April 2009 21:24
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy?
A weak reference listener is attached to myAc. It shouldn't matter what
its type is (as long as it isn't XML). The selectedChild of a ViewStack
will have a reference to the ModuleLoader child which should have a
reference to the module. Not sure how you are attempting to unload that
module, but once that gets cleaned up, the module should go away. The
profiler should help you see what is hanging onto the module.
The profiler should also give you good info on who's hanging onto the
editable copy.
Are you comfortable with working with the Profiler? Have you looked at
the profiler tutorial on my blog?
Alex Harui
Flex SDK Developer
Adobe Systems Inc. http://www.adobe.com/
Blog: http://blogs.adobe.com/aharui http://blogs.adobe.com/aharui
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
I'd have to poke through it to be sure, but it should. Fundamentally, all that
should be going on there is this:
CairngormNameChangedToProtectTheInnocentModel.getInstance().uploadsFromFoo.addEventListener(result,
bindingCallback, false, 0, true);
Where bindingCallback looks like:
private function bindingCallback(event:Event):void
{
uploadFromFoo.dataProvider =
CairngormNameChangedToProtectTheInnocentModel.getInstance().uploadsFromFoo.result
}
There should not be any strong references from
CairngormNameChangedToProtectTheInnocentModel to the DataGrid.
It gets a bit more tricky with the way MXML generates code and we've found bugs
in there in the past, but the ones I've explored recently haven't been a
problem.
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 Gregor Kiddie
Sent: Friday, May 01, 2009 1:38 AM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Hang on, now I'm confused...
Does this code result in a weak reference binding?
mx:DataGrid id = uploadFromFoo
width = 100%
height = 100%
dataProvider = {
CairngormNameChangedToProtectTheInnocentModel.getInstance().uploadsFromFoo }
allowMultipleSelection = false
change = viewHelper.uploadSelectionChange()
editable = false
I was always led to believe it wouldn't.
Gregor Kiddie
Senior Developer
INPS
Tel: 01382 564343
Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ
Registered Number: 1788577
Registered in the UK
Visit our Internet Web site at www.inps.co.ukblocked::http://www.inps.co.uk/
The information in this internet email is confidential and is intended solely
for the addressee. Access, copying or re-use of information in it by anyone
else is not authorised. Any views or opinions presented are solely those of the
author and do not necessarily represent those of INPS or any of its affiliates.
If you are not the intended recipient please contact is.helpd...@inps.co.uk
From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf
Of Alex Harui
Sent: 28 April 2009 21:24
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy?
A weak reference listener is attached to myAc. It shouldn't matter what its
type is (as long as it isn't XML). The selectedChild of a ViewStack will have
a reference to the ModuleLoader child which should have a reference to the
module. Not sure how you are attempting to unload that module, but once that
gets cleaned up, the module should go away. The profiler should help you see
what is hanging onto the module.
The profiler should also give you good info on who's hanging onto the editable
copy.
Are you comfortable with working with the Profiler? Have you looked at the
profiler tutorial on my blog?
Alex Harui
Flex SDK Developer
Adobe Systems Inc.http://www.adobe.com/
Blog: http://blogs.adobe.com/aharui
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Alex,
About weak reference listeners - what kind of listeners are created when
bindings are defined in MXML? Like dataProvider={myAc}? And would it
help to use [Bindable] myColl:ICollectionView as the source? I hear you
on trying to make things like this easy. I think the ViewStack loading
Modules conditionally is a pretty common scenario for app development.
One of the things I am seeing is that it easier to get the module to
unload if it isn't the currently selectedChild of the ViewStack, but so
far I get the best results when a brand new module is loaded before
exiting the application. Then the other module becomes relatively easy
to gc.
In my app, one of the modules manages a particular product type. Based
upon search criteria, a datagrid will be populated. If they want to
edit a given dg item, there's a popup editor which makes a copy of the
editable object and binds that to a form. The user makes edits and
chooses to save or not the item. Right now, that's what I'm focusing
on, because the editable copy I make seems to be hanging around in
memory after attempting to unload the module and might be contributing
to the problem.
Jeff
-Original Message-
From: flexcoders@yahoogroups.com
[mailto:flexcod...@yahoogroups.com] On Behalf Of Alex Harui
Sent: Monday, April 27, 2009 6:15 PM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Unloading Modules - Binding is the
Enemy?
I haven't looked at ModelLocator, but in general, if you have a
single instance of something and are binding to it from a module, code
in the module will add a listener to the single instance. This creates
a reference from the single instance to the module, but Binding should
be using a weak reference listener. Maybe it is time for me to build a
test case and look. We want to make this kind of thing easy. If
ModelLocator keeps its own list of subscribers, that could be a problem.
If your local models are listening for changes to the central model and
not using weak reference listeners that will also be a problem.
If the PopUp is being gc'd then that should no longer pin the
module. I haven't looked at many popup scenarios so there could be
something there. In general though, I've found the profiler will
eventually tell me the answer. I assume you know that new classes pin
modules if they bring in new Style definitions that get registerd with
the StyleManager.
That said, the Flash Player will not always gc() everything it
could in one pass, and sometimes does hang onto things a bit longer, so
the load/interact/unload/checkmemory test will not always succeed. If
loading the module again or loading a different module eventually causes
the release of the first module, we consider that success. Another
test we run is an overnight test of loading and unloading modules that
are published for release mode (no debug info) and run on the release
player instead of the debugger player. Memory should stabilize after a
while. The debugger player has a reputation for hanging on to things
that the release player won't because it is handling debug info in the
debug SWFs.
Alex Harui
Flex SDK Developer
Adobe Systems Inc. http://www.adobe.com/
Blog: http://blogs.adobe.com/aharui
http://blogs.adobe.com/aharui
From: flexcoders@yahoogroups.com
[mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff
Sent: Monday, April 27, 2009 11:36 AM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Unloading Modules - Binding is the
Enemy?
Thanks Alex, very much. The main app is only handling
login/logout duties and the event-command-delegate classes to do so. I
moved away from ModelLocator in the concern that it, being a singleton,
may be keeping a reference to UI objects that are using ModelLocator
objects as dataProviders and thus prevent a clean unload. After all, by
definition, a singleton is going to persist after a module is unloaded,
true? Maybe I was wrong about that, but I'll tell you, I was trying
everything to get that module to unload. Everyone was a suspect. Bear
with me while I try to get my wits around this stuff. What I'm doing
how is keeping all my models local to the module that uses them and
injecting data via command and delegate classes. This seems to work ok.
As far as PopUps, I'm calling removePopUp() and also removing
listeners to custom events I've defined in the popup.
I'm also seeing some behavior where the module will remain in
memory after unloading (as reported by the profiler) until I create a
new instance of that particular module class and populate the
dataProvider of one of its children. The holy grail of a 100% clean
module load/unload has not been attained, but I believe I'm
Re: [flexcoders] Unloading Modules - Binding is the Enemy?
Would be really helpful a removeAllEventListenerss() on event EventDispacher Or even a dispose() method on UIComponent class that remove listeners, clean references, and whatever else is necessary to clean memory. VELO On Mon, Apr 27, 2009 at 3:36 PM, Battershall, Jeff jeff.battersh...@dowjones.com wrote: Thanks Alex, very much. The main app is only handling login/logout duties and the event-command-delegate classes to do so. I moved away from ModelLocator in the concern that it, being a singleton, may be keeping a reference to UI objects that are using ModelLocator objects as dataProviders and thus prevent a clean unload. After all, by definition, a singleton is going to persist after a module is unloaded, true? Maybe I was wrong about that, but I'll tell you, I was trying everything to get that module to unload. Everyone was a suspect. Bear with me while I try to get my wits around this stuff. What I'm doing how is keeping all my models local to the module that uses them and injecting data via command and delegate classes. This seems to work ok. As far as PopUps, I'm calling removePopUp() and also removing listeners to custom events I've defined in the popup. I'm also seeing some behavior where the module will remain in memory after unloading (as reported by the profiler) until I create a new instance of that particular module class and populate the dataProvider of one of its children. The holy grail of a 100% clean module load/unload has not been attained, but I believe I'm getting closer. Jeff -Original Message- *From:* flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] *On Behalf Of *Alex Harui *Sent:* Monday, April 27, 2009 1:39 PM *To:* flexcoders@yahoogroups.com *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? Every time I’ve debugged a suspected Binding leak, I’ve found that it sets up weak references in the right places and the problem was always somewhere else. However, I wouldn’t bet against there being a scenario out there that does leak. We’re looking at other module unloading scenarios right now so I’d still be willing to look at a simple test case. IMHO, the main app should “never” reference the model. If you have a model Singleton, the module can bind to the singleton. IMHO, that’s a better model/view design anyway. I would expect all popups related to the module to be removed in order for the module to unload. One aspect of the modules design is that it does not require an unload() command. The design was that you would load a module and generate an instance (or several) of the module’s classes and once you’ve cleaned up all references to those instances, the module would go away in a future gc pass. That way, you wouldn’t have to track instances and know when it is time to call unload(). In order to implement such a design, the module SWF is given an unload() call right away so that its generated instances are supposedly the only remaining references to the modules classes thus preventing garbage-collection. Given the current design, I don’t think we can ever substitute unloadAndStop() for that unload call. Also, no testing has been done by the Flex team as to what impact unloadAndStop will have in ActionScript if references to objects suddenly become invalid. IMHO, unloadAndStop should only be used when there are well-defined boundaries such as around a sub-application since sub-apps tend to be more self-sufficient. Modules are much more tightly integrated with the main application. However, Modules or no Modules, we realize that debugging memory leaks is hard work. The Gumbo profiler has a new backreference display that eliminates most extraneous backreferences, and we welcome any other ideas for tools and techniques for finding leaks. 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 *Battershall, Jeff *Sent:* Monday, April 27, 2009 6:43 AM *To:* flexcoders@yahoogroups.com *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? Alex, I was using 3.2 - an oversight on my part - I upgraded to 3.3 and it does seem to help but I'm also calling focusManager.deactivate() as well. Since that, the combobox isn't an issue. However there any number of different things I was doing that were causing problems - like binding myModule.currentState to a model. One of the challenges is injecting model data into the module that doesn't create a refererence to the module anywhere. PopUpManager seems to be problematic if the popup contains strong refereneces to the module or its associated model. I am making progress and what I'm hoping for in the end is a definitive set of best practices concerning the use of modules. Hopefully some of these issues might
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
In most languages, including Actionscript, there is no way to know who is referencing some object without performing the same mark/sweep the gc() is doing (which violates the security of private variables to do so). The overhead of trying to track information like that would be significant which is why most runtimes to offer such a thing. Also, not every listener is the source of a leak. Employing good practices for cleanup is the better option. Maybe we need to converge on what those practices are. But I have been considering trying to see if we could write an AS method that can run the mark and figure it out. Ust don't have the time right now... 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 Marvin Froeder Sent: Tuesday, April 28, 2009 9:03 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Unloading Modules - Binding is the Enemy? Would be really helpful a removeAllEventListenerss() on event EventDispacher Or even a dispose() method on UIComponent class that remove listeners, clean references, and whatever else is necessary to clean memory. VELO On Mon, Apr 27, 2009 at 3:36 PM, Battershall, Jeff jeff.battersh...@dowjones.commailto:jeff.battersh...@dowjones.com wrote: Thanks Alex, very much. The main app is only handling login/logout duties and the event-command-delegate classes to do so. I moved away from ModelLocator in the concern that it, being a singleton, may be keeping a reference to UI objects that are using ModelLocator objects as dataProviders and thus prevent a clean unload. After all, by definition, a singleton is going to persist after a module is unloaded, true? Maybe I was wrong about that, but I'll tell you, I was trying everything to get that module to unload. Everyone was a suspect. Bear with me while I try to get my wits around this stuff. What I'm doing how is keeping all my models local to the module that uses them and injecting data via command and delegate classes. This seems to work ok. As far as PopUps, I'm calling removePopUp() and also removing listeners to custom events I've defined in the popup. I'm also seeing some behavior where the module will remain in memory after unloading (as reported by the profiler) until I create a new instance of that particular module class and populate the dataProvider of one of its children. The holy grail of a 100% clean module load/unload has not been attained, but I believe I'm getting closer. Jeff -Original Message- From: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com] On Behalf Of Alex Harui Sent: Monday, April 27, 2009 1:39 PM To: flexcoders@yahoogroups.commailto:flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Every time I've debugged a suspected Binding leak, I've found that it sets up weak references in the right places and the problem was always somewhere else. However, I wouldn't bet against there being a scenario out there that does leak. We're looking at other module unloading scenarios right now so I'd still be willing to look at a simple test case. IMHO, the main app should never reference the model. If you have a model Singleton, the module can bind to the singleton. IMHO, that's a better model/view design anyway. I would expect all popups related to the module to be removed in order for the module to unload. One aspect of the modules design is that it does not require an unload() command. The design was that you would load a module and generate an instance (or several) of the module's classes and once you've cleaned up all references to those instances, the module would go away in a future gc pass. That way, you wouldn't have to track instances and know when it is time to call unload(). In order to implement such a design, the module SWF is given an unload() call right away so that its generated instances are supposedly the only remaining references to the modules classes thus preventing garbage-collection. Given the current design, I don't think we can ever substitute unloadAndStop() for that unload call. Also, no testing has been done by the Flex team as to what impact unloadAndStop will have in ActionScript if references to objects suddenly become invalid. IMHO, unloadAndStop should only be used when there are well-defined boundaries such as around a sub-application since sub-apps tend to be more self-sufficient. Modules are much more tightly integrated with the main application. However, Modules or no Modules, we realize that debugging memory leaks is hard work. The Gumbo profiler has a new backreference display that eliminates most extraneous backreferences, and we welcome any other ideas for tools and techniques for finding leaks
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
A weak reference listener is attached to myAc. It shouldn't matter what its
type is (as long as it isn't XML). The selectedChild of a ViewStack will have
a reference to the ModuleLoader child which should have a reference to the
module. Not sure how you are attempting to unload that module, but once that
gets cleaned up, the module should go away. The profiler should help you see
what is hanging onto the module.
The profiler should also give you good info on who's hanging onto the editable
copy.
Are you comfortable with working with the Profiler? Have you looked at the
profiler tutorial on my blog?
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 Battershall, Jeff
Sent: Tuesday, April 28, 2009 6:26 AM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Alex,
About weak reference listeners - what kind of listeners are created when
bindings are defined in MXML? Like dataProvider={myAc}? And would it help to
use [Bindable] myColl:ICollectionView as the source? I hear you on trying to
make things like this easy. I think the ViewStack loading Modules
conditionally is a pretty common scenario for app development. One of the
things I am seeing is that it easier to get the module to unload if it isn't
the currently selectedChild of the ViewStack, but so far I get the best results
when a brand new module is loaded before exiting the application. Then the
other module becomes relatively easy to gc.
In my app, one of the modules manages a particular product type. Based upon
search criteria, a datagrid will be populated. If they want to edit a given dg
item, there's a popup editor which makes a copy of the editable object and
binds that to a form. The user makes edits and chooses to save or not the
item. Right now, that's what I'm focusing on, because the editable copy I make
seems to be hanging around in memory after attempting to unload the module and
might be contributing to the problem.
Jeff
-Original Message-
From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf
Of Alex Harui
Sent: Monday, April 27, 2009 6:15 PM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy?
I haven't looked at ModelLocator, but in general, if you have a single instance
of something and are binding to it from a module, code in the module will add a
listener to the single instance. This creates a reference from the single
instance to the module, but Binding should be using a weak reference listener.
Maybe it is time for me to build a test case and look. We want to make this
kind of thing easy. If ModelLocator keeps its own list of subscribers, that
could be a problem. If your local models are listening for changes to the
central model and not using weak reference listeners that will also be a
problem.
If the PopUp is being gc'd then that should no longer pin the module. I
haven't looked at many popup scenarios so there could be something there. In
general though, I've found the profiler will eventually tell me the answer. I
assume you know that new classes pin modules if they bring in new Style
definitions that get registerd with the StyleManager.
That said, the Flash Player will not always gc() everything it could in one
pass, and sometimes does hang onto things a bit longer, so the
load/interact/unload/checkmemory test will not always succeed. If loading the
module again or loading a different module eventually causes the release of the
first module, we consider that success. Another test we run is an overnight
test of loading and unloading modules that are published for release mode (no
debug info) and run on the release player instead of the debugger player.
Memory should stabilize after a while. The debugger player has a reputation
for hanging on to things that the release player won't because it is handling
debug info in the debug SWFs.
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 Battershall, Jeff
Sent: Monday, April 27, 2009 11:36 AM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Thanks Alex, very much. The main app is only handling login/logout duties and
the event-command-delegate classes to do so. I moved away from ModelLocator in
the concern that it, being a singleton, may be keeping a reference to UI
objects that are using ModelLocator objects as dataProviders and thus prevent a
clean unload. After all, by definition, a singleton is going to persist after
a module is unloaded, true? Maybe I was wrong about that, but I'll tell you, I
was trying everything to get that module
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
I can't find the bug either! I recall either Gordon or Alex talking about it though. Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk blocked::http://www.inps.co.uk/ The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: 24 April 2009 19:57 To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Gregor, It does seem to be connected to the ComboBox issue - is this in the Adobe BugBase? It doesn't turn up in my searches. I can get the reference to release if I navigate to another module and then logout, but if I change the selected index of the combo box to greater than -1 before that, it will not release no matter what I do. This is a royal PITA because my instantiation code is based upon a first time load of the module and if I cannot unload a module then my method of injecting model objects into my module will have to be re-done. If there's no workaround for this bug, then Modules are effectively broken if something as commonplace as a combobox prevents an unload. Jeff
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Alex, I was using 3.2 - an oversight on my part - I upgraded to 3.3 and it does seem to help but I'm also calling focusManager.deactivate() as well. Since that, the combobox isn't an issue. However there any number of different things I was doing that were causing problems - like binding myModule.currentState to a model. One of the challenges is injecting model data into the module that doesn't create a refererence to the module anywhere. PopUpManager seems to be problematic if the popup contains strong refereneces to the module or its associated model. I am making progress and what I'm hoping for in the end is a definitive set of best practices concerning the use of modules. Hopefully some of these issues might be made easier with somehting like loader.unloadAndStop() but for modules. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Alex Harui Sent: Friday, April 24, 2009 5:43 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Jeff, which version of Flex are you using? Can you make a test case in two 20-line mxml files? Alex Harui Flex SDK Developer Adobe Systems Inc. http://www.adobe.com/ Blog: http://blogs.adobe.com/aharui http://blogs.adobe.com/aharui From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: Friday, April 24, 2009 11:57 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Gregor, It does seem to be connected to the ComboBox issue - is this in the Adobe BugBase? It doesn't turn up in my searches. I can get the reference to release if I navigate to another module and then logout, but if I change the selected index of the combo box to greater than -1 before that, it will not release no matter what I do. This is a royal PITA because my instantiation code is based upon a first time load of the module and if I cannot unload a module then my method of injecting model objects into my module will have to be re-done. If there's no workaround for this bug, then Modules are effectively broken if something as commonplace as a combobox prevents an unload. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: Thursday, April 23, 2009 10:13 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Gregor, Very interesting indeed. If I login, load the module, interact with the combobox, logout, the instance remains in the profiler. However if I do all that and THEN load another module and logout, the number of instances of the first module goes to zero. These modules are being loaded into a ViewStack, BTW. Is this the FocusManager bug you described? Is there a workaround? I'd be thrilled to discover that Binding was not the culprit here. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Gregor Kiddie Sent: Thursday, April 23, 2009 9:40 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? It does sound like you are describing the bug where the focus manager holds onto the reference of the combo box and stops the module unloading... If you lose the combobox focus, does the module unload? Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk blocked::http://www.inps.co.uk/ The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Every time I've debugged a suspected Binding leak, I've found that it sets up weak references in the right places and the problem was always somewhere else. However, I wouldn't bet against there being a scenario out there that does leak. We're looking at other module unloading scenarios right now so I'd still be willing to look at a simple test case. IMHO, the main app should never reference the model. If you have a model Singleton, the module can bind to the singleton. IMHO, that's a better model/view design anyway. I would expect all popups related to the module to be removed in order for the module to unload. One aspect of the modules design is that it does not require an unload() command. The design was that you would load a module and generate an instance (or several) of the module's classes and once you've cleaned up all references to those instances, the module would go away in a future gc pass. That way, you wouldn't have to track instances and know when it is time to call unload(). In order to implement such a design, the module SWF is given an unload() call right away so that its generated instances are supposedly the only remaining references to the modules classes thus preventing garbage-collection. Given the current design, I don't think we can ever substitute unloadAndStop() for that unload call. Also, no testing has been done by the Flex team as to what impact unloadAndStop will have in ActionScript if references to objects suddenly become invalid. IMHO, unloadAndStop should only be used when there are well-defined boundaries such as around a sub-application since sub-apps tend to be more self-sufficient. Modules are much more tightly integrated with the main application. However, Modules or no Modules, we realize that debugging memory leaks is hard work. The Gumbo profiler has a new backreference display that eliminates most extraneous backreferences, and we welcome any other ideas for tools and techniques for finding leaks. 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 Battershall, Jeff Sent: Monday, April 27, 2009 6:43 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Alex, I was using 3.2 - an oversight on my part - I upgraded to 3.3 and it does seem to help but I'm also calling focusManager.deactivate() as well. Since that, the combobox isn't an issue. However there any number of different things I was doing that were causing problems - like binding myModule.currentState to a model. One of the challenges is injecting model data into the module that doesn't create a refererence to the module anywhere. PopUpManager seems to be problematic if the popup contains strong refereneces to the module or its associated model. I am making progress and what I'm hoping for in the end is a definitive set of best practices concerning the use of modules. Hopefully some of these issues might be made easier with somehting like loader.unloadAndStop() but for modules. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Alex Harui Sent: Friday, April 24, 2009 5:43 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Jeff, which version of Flex are you using? Can you make a test case in two 20-line mxml files? 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 Battershall, Jeff Sent: Friday, April 24, 2009 11:57 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Gregor, It does seem to be connected to the ComboBox issue - is this in the Adobe BugBase? It doesn't turn up in my searches. I can get the reference to release if I navigate to another module and then logout, but if I change the selected index of the combo box to greater than -1 before that, it will not release no matter what I do. This is a royal PITA because my instantiation code is based upon a first time load of the module and if I cannot unload a module then my method of injecting model objects into my module will have to be re-done. If there's no workaround for this bug, then Modules are effectively broken if something as commonplace as a combobox prevents an unload. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: Thursday, April 23, 2009 10:13 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Gregor, Very interesting indeed. If I login, load the module, interact with the combobox, logout, the instance remains in the profiler
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Thanks Alex, very much. The main app is only handling login/logout duties and the event-command-delegate classes to do so. I moved away from ModelLocator in the concern that it, being a singleton, may be keeping a reference to UI objects that are using ModelLocator objects as dataProviders and thus prevent a clean unload. After all, by definition, a singleton is going to persist after a module is unloaded, true? Maybe I was wrong about that, but I'll tell you, I was trying everything to get that module to unload. Everyone was a suspect. Bear with me while I try to get my wits around this stuff. What I'm doing how is keeping all my models local to the module that uses them and injecting data via command and delegate classes. This seems to work ok. As far as PopUps, I'm calling removePopUp() and also removing listeners to custom events I've defined in the popup. I'm also seeing some behavior where the module will remain in memory after unloading (as reported by the profiler) until I create a new instance of that particular module class and populate the dataProvider of one of its children. The holy grail of a 100% clean module load/unload has not been attained, but I believe I'm getting closer. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Alex Harui Sent: Monday, April 27, 2009 1:39 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Every time I've debugged a suspected Binding leak, I've found that it sets up weak references in the right places and the problem was always somewhere else. However, I wouldn't bet against there being a scenario out there that does leak. We're looking at other module unloading scenarios right now so I'd still be willing to look at a simple test case. IMHO, the main app should never reference the model. If you have a model Singleton, the module can bind to the singleton. IMHO, that's a better model/view design anyway. I would expect all popups related to the module to be removed in order for the module to unload. One aspect of the modules design is that it does not require an unload() command. The design was that you would load a module and generate an instance (or several) of the module's classes and once you've cleaned up all references to those instances, the module would go away in a future gc pass. That way, you wouldn't have to track instances and know when it is time to call unload(). In order to implement such a design, the module SWF is given an unload() call right away so that its generated instances are supposedly the only remaining references to the modules classes thus preventing garbage-collection. Given the current design, I don't think we can ever substitute unloadAndStop() for that unload call. Also, no testing has been done by the Flex team as to what impact unloadAndStop will have in ActionScript if references to objects suddenly become invalid. IMHO, unloadAndStop should only be used when there are well-defined boundaries such as around a sub-application since sub-apps tend to be more self-sufficient. Modules are much more tightly integrated with the main application. However, Modules or no Modules, we realize that debugging memory leaks is hard work. The Gumbo profiler has a new backreference display that eliminates most extraneous backreferences, and we welcome any other ideas for tools and techniques for finding leaks. Alex Harui Flex SDK Developer Adobe Systems Inc. http://www.adobe.com/ Blog: http://blogs.adobe.com/aharui http://blogs.adobe.com/aharui From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: Monday, April 27, 2009 6:43 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Alex, I was using 3.2 - an oversight on my part - I upgraded to 3.3 and it does seem to help but I'm also calling focusManager.deactivate() as well. Since that, the combobox isn't an issue. However there any number of different things I was doing that were causing problems - like binding myModule.currentState to a model. One of the challenges is injecting model data into the module that doesn't create a refererence to the module anywhere. PopUpManager seems to be problematic if the popup contains strong refereneces to the module or its associated model. I am making progress and what I'm hoping for in the end is a definitive set of best practices concerning the use of modules. Hopefully some of these issues might be made easier with somehting like loader.unloadAndStop() but for modules. Jeff -Original Message
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
I haven't looked at ModelLocator, but in general, if you have a single instance of something and are binding to it from a module, code in the module will add a listener to the single instance. This creates a reference from the single instance to the module, but Binding should be using a weak reference listener. Maybe it is time for me to build a test case and look. We want to make this kind of thing easy. If ModelLocator keeps its own list of subscribers, that could be a problem. If your local models are listening for changes to the central model and not using weak reference listeners that will also be a problem. If the PopUp is being gc'd then that should no longer pin the module. I haven't looked at many popup scenarios so there could be something there. In general though, I've found the profiler will eventually tell me the answer. I assume you know that new classes pin modules if they bring in new Style definitions that get registerd with the StyleManager. That said, the Flash Player will not always gc() everything it could in one pass, and sometimes does hang onto things a bit longer, so the load/interact/unload/checkmemory test will not always succeed. If loading the module again or loading a different module eventually causes the release of the first module, we consider that success. Another test we run is an overnight test of loading and unloading modules that are published for release mode (no debug info) and run on the release player instead of the debugger player. Memory should stabilize after a while. The debugger player has a reputation for hanging on to things that the release player won't because it is handling debug info in the debug SWFs. 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 Battershall, Jeff Sent: Monday, April 27, 2009 11:36 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Thanks Alex, very much. The main app is only handling login/logout duties and the event-command-delegate classes to do so. I moved away from ModelLocator in the concern that it, being a singleton, may be keeping a reference to UI objects that are using ModelLocator objects as dataProviders and thus prevent a clean unload. After all, by definition, a singleton is going to persist after a module is unloaded, true? Maybe I was wrong about that, but I'll tell you, I was trying everything to get that module to unload. Everyone was a suspect. Bear with me while I try to get my wits around this stuff. What I'm doing how is keeping all my models local to the module that uses them and injecting data via command and delegate classes. This seems to work ok. As far as PopUps, I'm calling removePopUp() and also removing listeners to custom events I've defined in the popup. I'm also seeing some behavior where the module will remain in memory after unloading (as reported by the profiler) until I create a new instance of that particular module class and populate the dataProvider of one of its children. The holy grail of a 100% clean module load/unload has not been attained, but I believe I'm getting closer. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Alex Harui Sent: Monday, April 27, 2009 1:39 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Every time I've debugged a suspected Binding leak, I've found that it sets up weak references in the right places and the problem was always somewhere else. However, I wouldn't bet against there being a scenario out there that does leak. We're looking at other module unloading scenarios right now so I'd still be willing to look at a simple test case. IMHO, the main app should never reference the model. If you have a model Singleton, the module can bind to the singleton. IMHO, that's a better model/view design anyway. I would expect all popups related to the module to be removed in order for the module to unload. One aspect of the modules design is that it does not require an unload() command. The design was that you would load a module and generate an instance (or several) of the module's classes and once you've cleaned up all references to those instances, the module would go away in a future gc pass. That way, you wouldn't have to track instances and know when it is time to call unload(). In order to implement such a design, the module SWF is given an unload() call right away so that its generated instances are supposedly the only remaining references to the modules classes thus preventing garbage-collection. Given the current design, I don't think we can ever substitute unloadAndStop() for that unload call. Also, no testing has been done by the Flex team as to what impact
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Gregor, It does seem to be connected to the ComboBox issue - is this in the Adobe BugBase? It doesn't turn up in my searches. I can get the reference to release if I navigate to another module and then logout, but if I change the selected index of the combo box to greater than -1 before that, it will not release no matter what I do. This is a royal PITA because my instantiation code is based upon a first time load of the module and if I cannot unload a module then my method of injecting model objects into my module will have to be re-done. If there's no workaround for this bug, then Modules are effectively broken if something as commonplace as a combobox prevents an unload. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: Thursday, April 23, 2009 10:13 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Gregor, Very interesting indeed. If I login, load the module, interact with the combobox, logout, the instance remains in the profiler. However if I do all that and THEN load another module and logout, the number of instances of the first module goes to zero. These modules are being loaded into a ViewStack, BTW. Is this the FocusManager bug you described? Is there a workaround? I'd be thrilled to discover that Binding was not the culprit here. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Gregor Kiddie Sent: Thursday, April 23, 2009 9:40 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? It does sound like you are describing the bug where the focus manager holds onto the reference of the combo box and stops the module unloading... If you lose the combobox focus, does the module unload? Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk blocked::http://www.inps.co.uk/ The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: 23 April 2009 14:32 To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? 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
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Jeff, which version of Flex are you using? Can you make a test case in two 20-line mxml files? 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 Battershall, Jeff Sent: Friday, April 24, 2009 11:57 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Gregor, It does seem to be connected to the ComboBox issue - is this in the Adobe BugBase? It doesn't turn up in my searches. I can get the reference to release if I navigate to another module and then logout, but if I change the selected index of the combo box to greater than -1 before that, it will not release no matter what I do. This is a royal PITA because my instantiation code is based upon a first time load of the module and if I cannot unload a module then my method of injecting model objects into my module will have to be re-done. If there's no workaround for this bug, then Modules are effectively broken if something as commonplace as a combobox prevents an unload. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: Thursday, April 23, 2009 10:13 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? Gregor, Very interesting indeed. If I login, load the module, interact with the combobox, logout, the instance remains in the profiler. However if I do all that and THEN load another module and logout, the number of instances of the first module goes to zero. These modules are being loaded into a ViewStack, BTW. Is this the FocusManager bug you described? Is there a workaround? I'd be thrilled to discover that Binding was not the culprit here. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Gregor Kiddie Sent: Thursday, April 23, 2009 9:40 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? It does sound like you are describing the bug where the focus manager holds onto the reference of the combo box and stops the module unloading... If you lose the combobox focus, does the module unload? Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.ukblocked::http://www.inps.co.uk/ The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: 23 April 2009 14:32 To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? 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
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 */
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
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 */
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 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 */
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
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
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
It does sound like you are describing the bug where the focus manager holds onto the reference of the combo box and stops the module unloading... If you lose the combobox focus, does the module unload? Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk blocked::http://www.inps.co.uk/ The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: 23 April 2009 14:32 To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? 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
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
Gregor, Very interesting indeed. If I login, load the module, interact with the combobox, logout, the instance remains in the profiler. However if I do all that and THEN load another module and logout, the number of instances of the first module goes to zero. These modules are being loaded into a ViewStack, BTW. Is this the FocusManager bug you described? Is there a workaround? I'd be thrilled to discover that Binding was not the culprit here. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Gregor Kiddie Sent: Thursday, April 23, 2009 9:40 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? It does sound like you are describing the bug where the focus manager holds onto the reference of the combo box and stops the module unloading... If you lose the combobox focus, does the module unload? Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk blocked::http://www.inps.co.uk/ The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: 23 April 2009 14:32 To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? 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
Re: [flexcoders] Unloading Modules - Binding is the Enemy?
Hi Jeff, Just curiosity, what Application Domain are you using? http://livedocs.adobe.com/flex/3/html/help.html?content=18_Client_System_Environment_5.html http://livedocs.adobe.com/flex/3/html/help.html?content=18_Client_System_Environment_5.html VELO On Thu, Apr 23, 2009 at 11:13 AM, Battershall, Jeff jeff.battersh...@dowjones.com wrote: Gregor, Very interesting indeed. If I login, load the module, interact with the combobox, logout, the instance remains in the profiler. However if I do all that and THEN load another module and logout, the number of instances of the first module goes to zero. These modules are being loaded into a ViewStack, BTW. Is this the FocusManager bug you described? Is there a workaround? I'd be thrilled to discover that Binding was not the culprit here. Jeff -Original Message- *From:* flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] *On Behalf Of *Gregor Kiddie *Sent:* Thursday, April 23, 2009 9:40 AM *To:* flexcoders@yahoogroups.com *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? It does sound like you are describing the bug where the focus manager holds onto the reference of the combo box and stops the module unloading… If you lose the combobox focus, does the module unload? Gk. *Gregor Kiddie* Senior Developer *INPS* Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk -- *From:* flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] *On Behalf Of *Battershall, Jeff *Sent:* 23 April 2009 14:32 *To:* flexcoders@yahoogroups.com *Subject:* RE: [flexcoders] Unloading Modules - Binding is the Enemy? 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
RE: [flexcoders] Unloading Modules - Binding is the Enemy?
I'm creating new ApplicationDomain just for the modules. -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Marvin Froeder Sent: Thursday, April 23, 2009 2:19 PM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Unloading Modules - Binding is the Enemy? Hi Jeff, Just curiosity, what Application Domain are you using? http://livedocs.adobe.com/flex/3/html/help.html?content=18_Client_System _Environment_5.html http://livedocs.adobe.com/flex/3/html/help.html?content=18_Client_Syste m_Environment_5.html VELO On Thu, Apr 23, 2009 at 11:13 AM, Battershall, Jeff jeff.battersh...@dowjones.com wrote: Gregor, Very interesting indeed. If I login, load the module, interact with the combobox, logout, the instance remains in the profiler. However if I do all that and THEN load another module and logout, the number of instances of the first module goes to zero. These modules are being loaded into a ViewStack, BTW. Is this the FocusManager bug you described? Is there a workaround? I'd be thrilled to discover that Binding was not the culprit here. Jeff -Original Message- From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Gregor Kiddie Sent: Thursday, April 23, 2009 9:40 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? It does sound like you are describing the bug where the focus manager holds onto the reference of the combo box and stops the module unloading... If you lose the combobox focus, does the module unload? Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: 23 April 2009 14:32 To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Unloading Modules - Binding is the Enemy? 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
