I was able to reproduce the behavior while using the references array and uncommenting the line:
references.splice( references.indexOf(lastInstance),1); It might be that Player holds a reference to the object spliced out because it does return it. In any case... I'd like to reiterate that it doesn't leak. It's just doing what Alex describes as out-run the GC because it's calling initialize on the sub component. Here's a screen shot from my system when I set the frame rate to 60 and the timer to 50ms. https://www.dropbox.com/s/1suqwzkc2scewph/Screenshot%202016-02-24%2008.05.37.png?dl=0 On Wed, Feb 24, 2016 at 9:58 AM, Alex Harui <aha...@adobe.com> wrote: > I removed the references array, slowed the timer down to 1 second and > found that if I hit the GC button in the profiler, the instance count goes > back to 1 or 2, which is correct, so NonLeakySubComponent is not leaking, > without having to delete layoutObject. Make sure you are looking at > instance count and not cumulative instances? > > It is possible to "out-run" or "overload" the GC. GC is trying hard not > to interrupt animation and isn't guaranteed to do a full sweep. If you do > need to create and dispose of lots of instances of something, recycling > old instances is likely to be worth the effort. That's why item renderers > are recycled in MX list controls. > > HTH, > -Alex > > On 2/24/16, 9:15 AM, "Alex Harui" <aha...@adobe.com> wrote: > > >I took a quick look at the test case (I haven't even tried it in the > >profiler yet). > > > >I assume the test case to run is LeakByReference.mxml. In the run() > >method, it keeps storing references to the new NonLeakySubComponent on > >every pass, so sure, if you don't splice out the references to the old > >ones, the references array is going to cause a memory leak. > > > >Are you saying if you are seeing a memory leak if you don't use the > >references array? > > > >-Alex > > > >On 2/24/16, 8:27 AM, "XaviConde" <javier.co...@gruposame.com> wrote: > > > >>Hi Clint, > >> > >>Flash Profiler has a functionality to force garbage collection. I press > >>the > >>button several times and there's no instance being freed. Besides, taking > >>a > >>memory snapshot also forces garbage collection. > >> > >>On the other hand, after several hours of Flash Profiling, I have found a > >>workaround by removing the property layoutObject: > >> > >> private function > removedFromStage(event:Event):void { > >> /* For good measure, the eventListener is > removed when no longer > >>needed > >>*/ > >> > parentApplication.removeEventListener(MouseEvent.CLICK, > >>mouseClickEvent); > >> > >>//Stops memory leak > >> this["layoutObject"]=null; > >> } > >> > >>By removing this property (which held a CanvasLayout object added > >>dynamically) now the memory usage is stable and Profiler never reports > >>more > >>than 1 instance of NonLeakySubcomponent ever in memory. > >> > >>For what I've learned from this example, calling initialize on the child > >>object being added creates several objects which reference the child > >>object > >>itself. But when removeChild() is called, some of these circular > >>references > >>still exist. By forcing the removal as I've done it seems the circular > >>reference is broken. > >> > >>I think it should be considered a bug, since removeChild() is not undoing > >>all the actions of addChild(). I'm not sure if by letting it run enough > >>time > >>GC would remove the leaked instances; forcing the garbage collection from > >>Flash Profiler has not removed them, or the related objects. This is > >>happening on the latest 4.6.15 SDK. > >> > >> > >> > >>-- > >>View this message in context: > >> > http://apache-flex-development.2333347.n4.nabble.com/Memory-leak-caused-b > >>y > >>-addChild-tp51677p51715.html > >>Sent from the Apache Flex Development mailing list archive at Nabble.com. > > > >
