I have been asked about this from various different angles and responded to it (often with ammo from others) in various different ways. I have decided to compile all info I can as a starting point to address questions hat typically come up from Flex customers regarding Flash Player Memory Management and Flash Player Garbage Collection.
CAVEAT: I am not a Player engineer and haven’t looked at the Flash Player code, but this is my understanding from several discussions with the engineers on the Flash Player and Flex Teams. (Some of this info is taken directly from emails, forum postings and conversations I have had with Alex Harui, Matt Chotin and Gordon Smith.)
Also, Grant Skinner goes into far more detail on his blog about Flash Player Memory management and Garbage Collection.
If you want to know more than the high level that I am going to address here you should check out his blog entries:
http://www.gskinner.com/blog/archives/2006/09/resource_manage.html
http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html
http://www.gskinner.com/blog/archives/2006/09/garbage_collect.html
The underlying Flash player is essentially a garbage collection memory model. That means that if nobody has a reference to an object, it will be collected and thrown out eventually. Thus, you never have to delete anything, just make sure all of your references to it are broken by removing objects from the displaylist, removing event listeners or using weak listeners where appropriate.
The Flash Player runs within the browser’s memory space and Firefox or IE give memory to the player. The browsers are then responsible for the memory and will release it to the heap.
Here is a general description of what is generally going onwith memory management as an app runs:
The Flash Player grabs OS memory in large chunks, divides them up into smaller chunks and allocates those small chunks to the application. As the number of small chunks dwindles, the player runs a GC pass to see
if any of those small chunks can be freed before we go to the OS for another big chunk. If the application is idle and nothing is accessing memory, nothing is going to force a GC pass so nothing will ever get freed.
So lets say the Flash Player allocated 40 megs. If the app happened to get to 33 megs there may be no need for the Player to GC. And it could be that in reality the Player could get away with only 20 megs, but it will take that whole 40 b/c the OS is letting it. Still not technically a memory leak, even if you think the Windows Task Manager should show less.
The MemoryMonitor tries to force a GC pass (see the hack comment in the code). It is unclear as to whether the hack works perfectly.
GC is opportunistic. This means it does not run all of the time. It tends to be triggered by allocating memory instead of freeing it, so watching an idle app will almost never result in GC. Because of the fact that GC is more or less “opportunistic”, there is no current way to manually test for memory leaks. I think there are situations where lots of activity forces several large chunks to be acquired from the OS and then, when most of that stuff is freed, each of the large chunks has a few small chunks still in use and so the OS chunks are not released back to the OS because there isn’t enough activity to cause a GC pass. Therefore, the only way we “prove” there is a memory leak issue is to use MemoryMonitor’s callback to repeat a sequence over and over again.
Now, lets look at an example.
Read the rest of this post»
No Comments »
Recent Comments