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.
>
