Why isn't the AS3 garbage collector picking this up? - actionscript-3

Question

I started running into serious issues with the garbage collector partially picking this up, but still leaving most of the object up and running in the background without a reference:
m_win = new MyWindow(arr);
m_win.open();
m_win.addEventListener(Event.CLOSE, onClose);
.
.
.
private function onClose(pEvent:Event):void
{
m_win.removeEventListener(Event.CLOSE, onClose);
m_win.close();
m_win = null;
// RAM usage for m_win is only reduced about 20-40%. I can see the garbage
// collector has run as a result of that reduction, but the other 60-80% are
// a serious problem.
}
That's the only event listener I have added to m_win, and that's the only reference my code has to m_win. MyWindow is basically a standalone AIR project (although it's nested in a different class than its own Main class to adapt it to work for this scenario; otherwise the same). MyWindow has NetConnections, NetStreams, and such that were kept live after the garbage collector would run.
So one of the first things I tried was to go in and disconnect its NetConnections and NetStreams. But that didn't work. Then I came across these blogs:
http://tomgabob.blogspot.com/2009/11/as3-memory-management.html
I found the link for that in another blog from another guy who had trouble with the same thing: Supposedly if AS3's garbage collector finds an "island" that has reached a critical mass (in my experience, maybe 30 MB?), it just refuses to do anything with it. So I went with this guy's recommendation and at least attempted to null out every reference, remove every event listener, call removeAllElements() and/or removeChildren() where necessary, and call "destructor" functions manually all throughout MyWindow, the sole exception being the Main class that isn't really used for m_win.
It didn't work, unless I messed up. But even if I left a couple of stones unturned, it should have still broken up the island more than enough for it to work. I've been researching other causes and work-arounds for this problem and have tried other things (such as manually telling the garbage collector to run), but nothing's cleaning the mess up properly. The only thing that has worked has been to disconnect the NetConnection/NetStream stuff on the way out, but a good 25-30 MB is remaining uncollected.
How can this be fixed? Thanks!
EDIT: Given Adobe's statements at http://www.adobe.com/devnet/actionscript/learning/as3-fundamentals/garbage-collection.html:
"GCRoots are never garbage collected."
and:
"The MMgc is considered a conservative collector for mark/sweep. The MMgc can't
tell if certain values in memory are object pointers (memory addresses) or a
numeric value. In order to prevent accidentally collecting objects the values
may point to, the MMgc assumes that every value could be a pointer. Therefore,
some objects that are not really being pointed to will never be collected and
will be considered a memory leak. Although you want to minimize memory leaks to
optimize performance, the occasional leaks that result from conservative GC tend
to be random, not to grow over time, and have much less of an impact on an
application's performance than leaks caused by developers."
I can see sort of a link between that and the "big island" theory at this point - assuming the theory is correct, which I'm not. Adobe's pretty much admitting at this point, in at least the second statement, that there are at least benign issues with orphans getting skipped over. They act like it's no big deal, but to just leave it like that and pretend it's nothing is probably mostly just typical Adobe sloppiness. What if one of those rare missed orphans that they mentioned has a large, fully-active object hierarchy within it? If you can't prevent the memory leak there completely, I could definitely see how going through and doing things like nulling out references all throughout that hierarchy before you lose your reference would generally do a lot to minimize the amount of memory leaked as a result.
My thinking is that the garbage collector would generally still be able to get rid of most of everything within that island, just not the island itself. Also what some of these people who were supposedly able to really use the "big island" theory were seeing was probably some of the "less benign" manifestations of what Adobe was admitting to. This remains a hypothesis though.
EDIT: After I checked again on the destructorsand straightened out a couple of issues, I did see a significant improvement. The reason I'm leaving this question up and going is that not only is there a chance I'm still missing something else I could be doing to release memory, but the main explanation I've used so far isn't official or proven.

Answer 1

try calling
try {
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
} catch (e:*) {}
// the GC will perform a full mark/sweep on the second call.
to force garbage collection. This is undocumented, but works.. credits to Grant Skinner, who explains more on his blog