This content has been marked as final. Show 8 replies
Make sure you aren't running into issues with the Timer class. In AS2, setInterval was notorious for causing huge leaks when used improperly. I'm guessing that the issue you're having or seeing is with garbage collection on the Timer class. Give that a shot first. I've not had any issue with loading and destroying swfs in AS3 up to this point and I often load as many as 15-20 into a single shell at a time and unload and reload at the same pace across the life of the application. This may not happen quickly but if what you're implying is true, my apps would be crashing as well and I haven't noticed anything yet. Up to now, I've not gotten around to using the new Timer class so that's where I'd look first.
Thanks for the response - unfortunately, I don't think this is really the case - if you check out what I'm doing with the timer class, it's pretty straightforward, right out of Adobe's help documentation. I don't think this is the issue. I still have the same problem when I run my application, which instantiates and later removes .swfs based on user action, not a timer - I'm seeing the same issue with memory in that application as well.
Any other ideas?
One idea - there is a separate stack of memory in the flash player where loaded classes in separate application domains exist, and these classes are not being garbage collected....however, there is a line in adobe's documentation here:
under "Usage C" :
Having a new application domain also allows you to unload all the class definitions for garbage collection, if you can ensure that you do not continue to have references to the child SWF.
Given that, as far as I can see from this code, there is no reference to the loaded .swf maintained....it seems to me like the loaded data (graphical assets AND classes) should be garbage collected - but, while you WILL see a slight drop in memory after the removal of the SWF, the overall memory continues to increase the more you do it. Could Adobe be mistaken?
i did some testing and verified a memory leak when played in the test environment but not when played in a browser. here are the trace results from the test environment:
and here are the trace results from the browser:
i did edit the class file somewhat to eliminate extraneous possible problems:
I haven't started using as3 yet, but I've read a little here about garbage collection in general and the use of weak references for events:
I can't see you removing the Timer event listener or using a weak reference when setting it up which would mean that it doesn't prevent garbage collection. Perhaps its the event listeners that are preventing the Timers being garbage collected. [I'm not sure, just thought I'd throw it out there- kglad's anaysis seems to point to something else]
EDIT: OOPS that's probably completely irrelevant sorry. I just looked at your code again. I guess that would possibly be relevant only if you were creating new instances of your MemoryLeak class, and even then the 'mark and sweep' garbage collection might catch it if I understand things correctly.
closer to the essence of the problem is the unload() method not working correctly in the test environment.
while it seems to do some things correctly, it's not clearing all the loaded data. you can confirm by checking the loader's contentLoaderInfo.bytesLoaded property even1 minute after a load and unload.
Thanks for the research!
As far as garbage collection goes, it seems to me that, so long as I null out the loader each time, create a new instance of the Loader class and assign it to my 'loader' variable, the previous loader (and it's associated contentLoaderInfo) should be garbage collected eventually, as there are no remaining references to it. This should work properly in the IDE or in the browser, i would assume.
I've also tested the loading and reloading in the browser and determined that the memory consumption stays about the same after a few loads. Thats good news. But, why in the IDE does it continue to hold onto data? Sounds like a bug to me.
yes, there's something wrong with the unload() method when used in the test environment.