Re: [flexcoders] Re: memory leaks and activation-objects
I don’t like anonymous functions, nested functions or whatever you want to call
function instances. Everything on the callstack is referenced by the
scope-chain/activation object until the function instance can be GC’d. Once
you call removeEventLIstener, then the scope-chain goes away, but until then,
lots of things are kept around.
It is generallyl more efficient to make doSomething a member method on the
class. Or create a helper class that handles the dialog and stores the x,y,z
values.
When you originally posted I thought you were saying that an activation object
that should go away wasn’t or was blocking other things from going away.
AFAIK, that isn’t true, but activation objects are kept around by references to
function instances and can lead to unexpected memory usage.
On 8/31/10 7:53 AM, lew.miller lew.mil...@gmail.com wrote:
Yes. That's precisely what I'm doing. Only, looking at the code now I realize
most of the time I'm using nested functions (with names) rather than anonymous
functions. I'm not sure what the implications are of using one over another
are but, regardless, I gather you're suggesting this is a potential problem?
A typical example of what I'm doing would be something like:
private function showDialog(x,y,z):void
{
var dialog:SomeDialog = new SomeDialog();
dialog.addEventListener(ok, function doSomething(e:DialogEvent):void
{
someMethod(x,y,z);
}
dialog.show();
}
I'm using the nested function because I need some way to get the x,y,z values
into someMethod. Does this code look problematic?
Thanks much for your help!
Lew
--- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Alex
Harui aha...@... wrote:
Could you be registering anonymous functions as event listeners and other
callbacks?
On 8/30/10 12:52 PM, lew.miller lew.mil...@... wrote:
Thanks Alex. I don't have any simple test case indicating that they leak,
I'm just struggling to understand what is causing certain leaks in a large
application where the profiler points me to activation objects.
So when tracking memory leaks with the FB4 profiler you're saying one
can/should simply ignore any object reference paths that start with
activation objects? (If so, it would be nice if they weren't reported--but
that's a separate issue.) Can you tell me what it means when the profiler
lists activation objects? Does that imply some corresponding function is
executing at the time the memory snapshot was taken? If I understood why I'm
getting all these references from activation objects I'd feel a bit more
comfortable about ignoring them. :-)
My application makes use of anonymous functions in places and I read an old
Adobe Developer Connection article that says:
Defining functions on the fly causes an arcane memory leak in Flash Player
because the activation object sent to the function can never be recovered by
the garbage collector. So the bottom line is to avoid dynamic classes and
explicitly define all the properties and functions used in your classes.
It doesn't elaborate and was written in 2006 so it may be irrelevant but
makes me wonder.
--- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com
mailto:flexcoders%40yahoogroups.com , Alex Harui aharui@ wrote:
AFAIK, they do not cause leaks. If you show some data or a simple test
case that indicates that they are, I will try to take a look.
On 8/30/10 8:36 AM, lew.miller lew.miller@ wrote:
I've been wrestling with memory leaks and the FB4 profiler and lately have
been trying to understand activation-objects and their relationship to GC
because the vast majority (often all) of the references the profiler tells
me an object has keeping it in memory come from activation objects.
While researching this I came across a note from Alex Harui saying I've
never seen an activation object cause a leak but other things I've read
seem to suggest they can. (Certainly the profiler would lead me to believe
it.) Can anybody enlighten me? Or just point me to the place to read
documentation on the subject that is up-to-date? Half of what I've read
about activation objects appears to be from earlier versions of
ActionScript so I'm not sure what to believe.
If an activation object can cause a memory leak, I'd like to understand
how. I may not have a firm grasp of the lifecycle of an activation object
but I thought it would no longer be accessible from the GC root after the
function it's created for finishes executing.
Any help or pointers would be greatly appreciated.
Lew
--
Alex Harui
Flex SDK Team
Adobe System, Inc.
http://blogs.adobe.com/aharui
--
Alex Harui
Flex SDK Team
Adobe System, Inc.
http://blogs.adobe.com/aharui
--
Alex Harui
Flex SDK Team
Adobe System, Inc.
http://blogs.adobe.com/aharui
Re: [flexcoders] Re: memory leaks and activation-objects
Could you be registering anonymous functions as event listeners and other callbacks? On 8/30/10 12:52 PM, lew.miller lew.mil...@gmail.com wrote: Thanks Alex. I don't have any simple test case indicating that they leak, I'm just struggling to understand what is causing certain leaks in a large application where the profiler points me to activation objects. So when tracking memory leaks with the FB4 profiler you're saying one can/should simply ignore any object reference paths that start with activation objects? (If so, it would be nice if they weren't reported--but that's a separate issue.) Can you tell me what it means when the profiler lists activation objects? Does that imply some corresponding function is executing at the time the memory snapshot was taken? If I understood why I'm getting all these references from activation objects I'd feel a bit more comfortable about ignoring them. :-) My application makes use of anonymous functions in places and I read an old Adobe Developer Connection article that says: Defining functions on the fly causes an arcane memory leak in Flash Player because the activation object sent to the function can never be recovered by the garbage collector. So the bottom line is to avoid dynamic classes and explicitly define all the properties and functions used in your classes. It doesn't elaborate and was written in 2006 so it may be irrelevant but makes me wonder. --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Alex Harui aha...@... wrote: AFAIK, they do not cause leaks. If you show some data or a simple test case that indicates that they are, I will try to take a look. On 8/30/10 8:36 AM, lew.miller lew.mil...@... wrote: I've been wrestling with memory leaks and the FB4 profiler and lately have been trying to understand activation-objects and their relationship to GC because the vast majority (often all) of the references the profiler tells me an object has keeping it in memory come from activation objects. While researching this I came across a note from Alex Harui saying I've never seen an activation object cause a leak but other things I've read seem to suggest they can. (Certainly the profiler would lead me to believe it.) Can anybody enlighten me? Or just point me to the place to read documentation on the subject that is up-to-date? Half of what I've read about activation objects appears to be from earlier versions of ActionScript so I'm not sure what to believe. If an activation object can cause a memory leak, I'd like to understand how. I may not have a firm grasp of the lifecycle of an activation object but I thought it would no longer be accessible from the GC root after the function it's created for finishes executing. Any help or pointers would be greatly appreciated. Lew -- Alex Harui Flex SDK Team Adobe System, Inc. http://blogs.adobe.com/aharui -- Alex Harui Flex SDK Team Adobe System, Inc. http://blogs.adobe.com/aharui
RE: [flexcoders] Re: Memory leaks?
Any time you load a module, its SWF gets uncompressed, parsed and then executed until the code runs that notifies the moduleloader that it is ready. SWF parsing is not nearly as efficient as EXE processing, but of course, not nearly as fast as just creating a new instance of the main class in the module. I will mention that modules often don't unload if they have styles registered with StyleManager so it may be that your modules aren't unloading anyway. The performance profiler will help you see where time is going. From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of tchredeemed Sent: Friday, January 16, 2009 1:15 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Memory leaks? does the module loading itself really effect performance?
RE: [flexcoders] Re: Memory leaks in a asyncronic operation
I don't know what books and other materials are out there. Note that there are filters that don't show certain classes. Maybe they are hiding the true leak From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of cavi21 Sent: Tuesday, June 03, 2008 5:05 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Memory leaks in a asyncronic operation Hello Alex, thanks for your reply, I've been using it, and the only thing that i found is an instance of BitString defined in the custom class i'm using to encode , that is not leave memory after the method that create it ended. On the other hand, if i use the native class, this instance never appears in the Profiler. Is there any good book or guide that helps to take full profit of the Profiler?? thanks --- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com , Alex Harui [EMAIL PROTECTED] wrote: The Flex3 Profiler can help you find memory leaks From: flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com [mailto:flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com ] On Behalf Of cavi21 Sent: Monday, June 02, 2008 2:10 PM To: flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com Subject: [flexcoders] Memory leaks in a asyncronic operation Hello, i've been searching for a while to a solution to this problem, and i've been trying myself, with no succeed. The problem is this, i'm encoding to JPEG six bitmap captures from a webcam stream in a video component. Up to here, is no problem. But if I used the native class to encode (mx.graphics.codec.JPEGEncoder) the AIR application hang for 2 minutes processing the images. In these case at the end of the process i call a function to free up the memory, and everything works fine. The problem is that i'm using a modified class to encode (http://blog.paranoidferret.com/index.php/2007/12/11/flex-tutorial-an-as http://blog.paranoidferret.com/index.php/2007/12/11/flex-tutorial-an-as ynchronous-jpeg-encoder/ http://blog.paranoidferret.com/index.php/2007/12/11/flex-tutorial-an-as http://blog.paranoidferret.com/index.php/2007/12/11/flex-tutorial-an-as ynchronous-jpeg-encoder/ ) . The benefit is that i can show a progressbar showing the encoding process. But the only problem that i have is that, at the end of the process, i have memory hang up... i've been reading that these may occur without a proper care in the events listeners. Sory about my english, is not ma native language, and thanks in advance for your time and patience.
Re: [flexcoders] Re: Memory leaks
Hi there,
Sometime ago I developed a simple kind of memory monitor to track down the
garbage collection activity and cycles.
In short the application is a kind of flash player memory monitor. You can
see it at http://www.
code4net.com/memoryTest/http://www.code4net.com/memoryTest/
It has to graphics:
- The left one takes an snapshot of the player used memory every 200ms. It
takes a maximum of 200 samples in a ciclic way.
- The right one is an average of the left graphic. It takes the last 50
samples of the left graph and gets the averaged value.
The application takes advantage of the player shared memory so if you are
running two diferent swf in two diferent tabs of firefox or IE the monitor
will be showing the memory usage of the other swf.
Compiling your application I do not appreciate a continuos increment on the
memory usage if creating and removing several times the children. But if I
provoke the GC some memory is freed.
The initial increase of memory usage I suspect is due to some singletons and
managers first time initialization process. Being a singleton implies the
class is kept in memory and never freed because some references are kept.
HTH
Xavi Beumala
On 8/29/07, Alex Harui [EMAIL PROTECTED] wrote:
Such is the nature of player memory management. It doesn't free up pages
as aggressively as you might want it to, nor does it compact memory, so the
first allocation grabbed a bunch of pages that aren't fully cleaned, but
reused after that.
--
*From:* Gordon Smith
*Sent:* Wednesday, August 29, 2007 12:37 PM
*To:* flexcoders@yahoogroups.com
*Cc:* Alex Harui
*Subject:* RE: [flexcoders] Re: Memory leaks
Here are the results I get when I start by doing Force GC and Capture
Memory and then repeatedly do Add Childs, Rem Childs, Force GC, Capture
Memory:
4943872
6393856
6664192
6627328
6770688
6803456
6815744
6815744
6815744
6823936
6815744
There is no memory leak because continuing to add and remove children does
not continue to use more memory. However, I'm not sure what explains the
initial increase from 4.9MB to 6.8MB, and why it takes more than one cycle
to get to more-or-less steady-state. Any ideas, Alex?
- Gordon
--
*From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On
Behalf Of *filipemlopes
*Sent:* Tuesday, August 28, 2007 6:52 PM
*To:* flexcoders@yahoogroups.com
*Subject:* [flexcoders] Re: Memory leaks
Oh. It's to bad !!!
Does anybody know to solve this problem ??
--- In flexcoders@yahoogroups.com flexcoders%40yahoogroups.com, André
Rodrigues Pena
[EMAIL PROTECTED] wrote:
?xml version=1.0 encoding=utf-8?
mx:Application xmlns:mx=http://www.adobe.com/2006/mxml;
layout=vertical
mx:VBox id=vBoxLeak width=200 height=200
backgroundColor=#ee/
mx:HBox
mx:Button id=btnAddChilds label=Add Childs
click=onAddChilds_Click(event)/
mx:Button id=btnRemChilds label=Rem Childs
click=onRemChilds_Click(event)/
/mx:HBox
mx:HBox
mx:Button id=forceGC label=Force GC
click=onForceGB_Click(event)/
/mx:HBox
mx:HBox
mx:Button id=btnCaptureMemory label=Capture Memory
click=onCaptureMemory_Click(event)/
/mx:HBox
mx:TextArea id=txtArea width=200 height=200
textAlign=right/
mx:Script
![CDATA[
import mx.controls.Button;
private function onAddChilds_Click
(event:MouseEvent):void
{
for (var i:int=0;i1000;i++)
{
vBoxLeak.addChild(new Button);
}
}
private function onRemChilds_Click
(event:MouseEvent):void
{
vBoxLeak.removeAllChildren();
}
private function onCaptureMemory_Click
(event:MouseEvent):void
{
txtArea.text += System.totalMemory + \n;
}
private function onForceGB_Click(event:MouseEvent):void
{
// unsupported hack that seems to force a full GC
try
{
var lc1:LocalConnection = new LocalConnection();
var lc2:LocalConnection = new LocalConnection();
lc1.connect('name');
lc2.connect('name');
}
catch (e:Error)
{
}
}
]]
/mx:Script
/mx:Application
On 8/27/07, André Rodrigues Pena [EMAIL PROTECTED] wrote:
Alex, I appreciate your reply but I still think there's something
wrong
regarding memory. I'm sending you an application that reproduces
the
situation I started my earlier post with. Flex does not releases
all the
memory it takes, even inducing garbage collection as I show in
the demo
application. If you repeat the experience over and over you will
see that
the memory lost is not likely to get back.
So what is this? What can I do about it?
On 8/25/07, Alex Harui [EMAIL PROTECTED] wrote:
There are two major memory usage scenarios in Flex. One
involves
creating a new instance of a component, displaying, and later
destroying
it. The other involves bringing in one or more classes of
components in a
module and trying to get rid of that module later when its
classes are no
longer needed
RE: [flexcoders] Re: Memory leaks
Here are the results I get when I start by doing Force GC and Capture Memory
and then repeatedly do Add Childs, Rem Childs, Force GC, Capture Memory:
4943872
6393856
6664192
6627328
6770688
6803456
6815744
6815744
6815744
6823936
6815744
There is no memory leak because continuing to add and remove children does not
continue to use more memory. However, I'm not sure what explains the initial
increase from 4.9MB to 6.8MB, and why it takes more than one cycle to get to
more-or-less steady-state. Any ideas, Alex?
- Gordon
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of
filipemlopes
Sent: Tuesday, August 28, 2007 6:52 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Memory leaks
Oh. It's to bad !!!
Does anybody know to solve this problem ??
--- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com ,
André Rodrigues Pena
[EMAIL PROTECTED] wrote:
?xml version=1.0 encoding=utf-8?
mx:Application xmlns:mx=http://www.adobe.com/2006/mxml
http://www.adobe.com/2006/mxml
layout=vertical
mx:VBox id=vBoxLeak width=200 height=200
backgroundColor=#ee/
mx:HBox
mx:Button id=btnAddChilds label=Add Childs
click=onAddChilds_Click(event)/
mx:Button id=btnRemChilds label=Rem Childs
click=onRemChilds_Click(event)/
/mx:HBox
mx:HBox
mx:Button id=forceGC label=Force GC
click=onForceGB_Click(event)/
/mx:HBox
mx:HBox
mx:Button id=btnCaptureMemory label=Capture Memory
click=onCaptureMemory_Click(event)/
/mx:HBox
mx:TextArea id=txtArea width=200 height=200
textAlign=right/
mx:Script
![CDATA[
import mx.controls.Button;
private function onAddChilds_Click
(event:MouseEvent):void
{
for (var i:int=0;i1000;i++)
{
vBoxLeak.addChild(new Button);
}
}
private function onRemChilds_Click
(event:MouseEvent):void
{
vBoxLeak.removeAllChildren();
}
private function onCaptureMemory_Click
(event:MouseEvent):void
{
txtArea.text += System.totalMemory + \n;
}
private function onForceGB_Click(event:MouseEvent):void
{
// unsupported hack that seems to force a full GC
try
{
var lc1:LocalConnection = new LocalConnection();
var lc2:LocalConnection = new LocalConnection();
lc1.connect('name');
lc2.connect('name');
}
catch (e:Error)
{
}
}
]]
/mx:Script
/mx:Application
On 8/27/07, André Rodrigues Pena [EMAIL PROTECTED] wrote:
Alex, I appreciate your reply but I still think there's something
wrong
regarding memory. I'm sending you an application that reproduces
the
situation I started my earlier post with. Flex does not releases
all the
memory it takes, even inducing garbage collection as I show in
the demo
application. If you repeat the experience over and over you will
see that
the memory lost is not likely to get back.
So what is this? What can I do about it?
On 8/25/07, Alex Harui [EMAIL PROTECTED] wrote:
There are two major memory usage scenarios in Flex. One
involves
creating a new instance of a component, displaying, and later
destroying
it. The other involves bringing in one or more classes of
components in a
module and trying to get rid of that module later when its
classes are no
longer needed.
Honestly, I don't know of any issues of the first kind at this
point. A
major problem with ViewStack related components was addressed
in Hotfix2,
and a DateField issue was either addressed in the same hotfix,
or a
workaround was provided and the issue fixed for Moxie. A
recent issue with
Menus was fixed for Moxie and a workaround was provided. I'm
sure there are
still issues out there, and they should be filed as bugs so we
can
investigate and fix them. I also encourage you to try to
isolate problems
of this nature and post examples on this forum as often there
can be a
misunderstanding of how memory management works in Flash/Flex.
The second kind of issues is sort of a fact-of-life for Flex.
The first
module to introduce shared code via Styles or Managers must
remain in memory
to serve all other code. This has been explained on my
blog.http://blogs.adobe.com/aharui/2007/03/modules.html.
blog.http://blogs.adobe.com/aharui/2007/03/modules.html.
The blog article includes an example of a way to deal with this
situation,
although often the easiest way is just to include all managers
in the main
app, and bring in styles via runtime CSS.
As you'll see in the article, browser memory management has
little to do
with it. It simply has to do with how GC works (described
further elsewhere
on my blog) and how styles and singleton managers are shared.
Any memory
changes when minimizing is probably due to IE releasing its own
browser
resources, although the player may release some at that time as
well.
If you have further questions, this forum should be able to
help you
out. In the future, please ask sooner before you spend time
creating
RE: [flexcoders] Re: Memory leaks
Such is the nature of player memory management. It doesn't free up pages as
aggressively as you might want it to, nor does it compact memory, so the first
allocation grabbed a bunch of pages that aren't fully cleaned, but reused after
that.
From: Gordon Smith
Sent: Wednesday, August 29, 2007 12:37 PM
To: flexcoders@yahoogroups.com
Cc: Alex Harui
Subject: RE: [flexcoders] Re: Memory leaks
Here are the results I get when I start by doing Force GC and Capture Memory
and then repeatedly do Add Childs, Rem Childs, Force GC, Capture Memory:
4943872
6393856
6664192
6627328
6770688
6803456
6815744
6815744
6815744
6823936
6815744
There is no memory leak because continuing to add and remove children does not
continue to use more memory. However, I'm not sure what explains the initial
increase from 4.9MB to 6.8MB, and why it takes more than one cycle to get to
more-or-less steady-state. Any ideas, Alex?
- Gordon
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of
filipemlopes
Sent: Tuesday, August 28, 2007 6:52 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Memory leaks
Oh. It's to bad !!!
Does anybody know to solve this problem ??
--- In flexcoders@yahoogroups.com mailto:flexcoders%40yahoogroups.com ,
André Rodrigues Pena
[EMAIL PROTECTED] wrote:
?xml version=1.0 encoding=utf-8?
mx:Application xmlns:mx=http://www.adobe.com/2006/mxml
http://www.adobe.com/2006/mxml
layout=vertical
mx:VBox id=vBoxLeak width=200 height=200
backgroundColor=#ee/
mx:HBox
mx:Button id=btnAddChilds label=Add Childs
click=onAddChilds_Click(event)/
mx:Button id=btnRemChilds label=Rem Childs
click=onRemChilds_Click(event)/
/mx:HBox
mx:HBox
mx:Button id=forceGC label=Force GC
click=onForceGB_Click(event)/
/mx:HBox
mx:HBox
mx:Button id=btnCaptureMemory label=Capture Memory
click=onCaptureMemory_Click(event)/
/mx:HBox
mx:TextArea id=txtArea width=200 height=200
textAlign=right/
mx:Script
![CDATA[
import mx.controls.Button;
private function onAddChilds_Click
(event:MouseEvent):void
{
for (var i:int=0;i1000;i++)
{
vBoxLeak.addChild(new Button);
}
}
private function onRemChilds_Click
(event:MouseEvent):void
{
vBoxLeak.removeAllChildren();
}
private function onCaptureMemory_Click
(event:MouseEvent):void
{
txtArea.text += System.totalMemory + \n;
}
private function onForceGB_Click(event:MouseEvent):void
{
// unsupported hack that seems to force a full GC
try
{
var lc1:LocalConnection = new LocalConnection();
var lc2:LocalConnection = new LocalConnection();
lc1.connect('name');
lc2.connect('name');
}
catch (e:Error)
{
}
}
]]
/mx:Script
/mx:Application
On 8/27/07, André Rodrigues Pena [EMAIL PROTECTED] wrote:
Alex, I appreciate your reply but I still think there's something
wrong
regarding memory. I'm sending you an application that reproduces
the
situation I started my earlier post with. Flex does not releases
all the
memory it takes, even inducing garbage collection as I show in
the demo
application. If you repeat the experience over and over you will
see that
the memory lost is not likely to get back.
So what is this? What can I do about it?
On 8/25/07, Alex Harui [EMAIL PROTECTED] wrote:
There are two major memory usage scenarios in Flex. One
involves
creating a new instance of a component, displaying, and later
destroying
it. The other involves bringing in one or more classes of
components in a
module and trying to get rid of that module later when its
classes are no
longer needed.
Honestly, I don't know of any issues of the first kind at this
point. A
major problem with ViewStack related components was addressed
in Hotfix2,
and a DateField issue was either addressed in the same hotfix,
or a
workaround was provided and the issue fixed for Moxie. A
recent issue with
Menus was fixed for Moxie and a workaround was provided. I'm
sure there are
still issues out there, and they should be filed as bugs so we
can
investigate and fix them. I also encourage you to try to
isolate problems
of this nature and post examples on this forum as often there
can be a
misunderstanding of how memory management works in Flash/Flex.
The second kind of issues is sort of a fact-of-life for Flex.
The first
module to introduce shared code via Styles or Managers must
remain in memory
to serve all other code. This has been explained on my
blog.http://blogs.adobe.com/aharui/2007/03/modules.html.
blog.http://blogs.adobe.com/aharui/2007/03/modules.html.
The blog article includes an example of a way to deal with this
situation,
although often the easiest way is just to include all managers
in the main
app, and bring in styles via runtime CSS.
As you'll see in the article, browser memory management has
little to do
