September 04, 2009
Flash Player Memory Management

Whilst working with some huge bitmaps for Aviary I had to face the undeniable fact that huge bitmaps are memory hogs and that the memory that is made available to the Flash Player by the browser is not unlimited. Actually it is quite limited - on my Vista machine that has 4GB of RAM I max out the memory at ca 1.5GB in FireFox 3.5.2. - that theoretically allows to keep 25 of the 64MB 4095*4095 bitmaps in memory which are the maximum sized bitmaps that Flash Player 10 allows for.

In practice it turns out though that this value is much smaller, the reason for it I learned from Joa: memory fragmentation does have a big impact on how big the chunks of memory can be that you can allocate at a certain time. So while you might be able to create 4 bitmaps of 10 MB each you might not be able to create a single one of 40MB.

But being limited to "just" 1.5GB is unfortunately not the end of the story. It shows that in most browsers (like FireFox 3.5.2) these ca. 1.5GB are not available to every SWF individually. No, all SWFs in all open tabs or windows of Firefox are sharing that one Pool of 1.5GB. That means the more one SWF requests the less is available for the others.

So in order that you can figure out what is happening yourself I've built MemoryHog, a tiny tool which will allocate and release memory. When you open multiple instances of it in your browser of choice you can see how memory is managed between all the open SWFs. A warning though: some browsers in some systems do crash when you press the "request maximum" button. Seems like Macs are more susceptible to this than PCs.

One thing you can see very good with MemoryHog is the influence of memory fragmentation. Sometimes whilst you cannot allocate a 100MB block anymore you are still able to get more than 10 10MB blocks.

My resume for Aviary: whilst it it nice to be able to finally use bigger bitmaps in Flash player 10 when it comes to using more than a few of them at the same time we will have to think about a implementing a tile based solution that makes better use of the fragmenting memory.

Posted at September 04, 2009 04:35 PM | Further reading

opened MemoryHog and requested Maximum. Opened a second Tab and displayed my Icebreaker snippet...

Result: Firefox crashed down in a hurry.

Posted by: frank on September 4, 2009 06:49 PM

I've been curious to learn more about the mysteries of Flash Memory Managment. It still seems to be quite a black box. Your tool sounds like a good start to clear up the haze. Thanks for the effort!

Keep up the good work!


Posted by: Michel on September 4, 2009 06:51 PM

garbage collection on safari 4/flash 10/ppc doesn't seem to do anything. what should it do?

Posted by: danny on September 4, 2009 07:29 PM

"Garbage collection" is more of a placebo button in order to prevent smart people from saying "yes, but you forgot that there is garbage collection which will make everything good again." When you press it it will call System.gc() twice. And as you correctly noticed it does not have any additional effect.

Posted by: Mario Klingemann on September 4, 2009 09:37 PM

I'm confused - I looked all over (awesome site btw), and I didn't see where the use of more than 4-5 4095x4095 bitmaps would ever really be needed. I may have missed it...

25 bitmaps of that size seems a little ridiculous - Can you give me an example of when you'd ever need 20+, or even 10+?

Posted by: Matt Bolt on September 6, 2009 06:08 PM

In Peacock you can easily reach that number very quickly. That's due to the nature how it is build. In order to speed up the rendering process each hub caches its result. If I wouldn't do that every little change in a parameter would require me to rerender the whole tree.

Also in Phoenix you can reach that limit since every layer is a bitmapData and in order for the undo function to work you have to keep copies of the changed areas in memory as well.

Posted by: Mario Klingemann on September 6, 2009 06:36 PM

Interesting. Any chance I could examine your source for MemoryHog?

Posted by: NateJC on September 8, 2009 08:20 PM

The part that tries to grab all the memory looks like this:

dim = 3621
while ( true )
maps.push( new BitmapData( dim, dim, true, 0 ) );
currRequested += dim * dim * 4;
} catch ( e:Error)
if ( dim > 1000 )
dim >>= 1;
} else {

Posted by: Mario Klingemann on September 8, 2009 09:05 PM

"That's due to the nature how it is build. In order to speed up the rendering process each hub caches its result."

Did you think of using a local shared object as cache? I am not sure if it would be fast enough though.

Greetz Erik

Posted by: Erik on September 10, 2009 10:07 PM

Yes we thought of that. It is an option, but we will probably not use it on a regular base but rather have that working in the background with hubs that don't get used for a while. We are also testing options like to convert rarely used bitmaps to bytearrays and then run compress() over them. Again since compress does not work asynchronous it will stall the application when a big bitmap is compressed this way. Also the way compress() is built there is a good chance that you run into out-of-memory errors whilst compressing. I wish Adobe would add some optional arguments that allow the control the greediness of the compression algorithm.

Posted by: Mario Klingemann on September 10, 2009 10:29 PM


Liked your site. Its cool.

My current project is dealing with problem huge memory allocations for large graphs. Memory once allocated does not comes down, due to the nature of Flex's GC. On your site I see that you were able to overcome the limitation by releasing the memory.

Can you please provide the know-how of how you were able to achieve that?


Posted by: Nits on October 12, 2009 02:11 PM

Sorry to disappoint you, but I have no secret "release memory" switch. All I am doing is to dispose the bitmaps that I have previouly created to allocate memory. If you want to be 100% sure not to leave any memory leaks you better do not use Flex in the first place since you have not real control over what is going on under the hood.

Posted by: Mario Klingemann on October 12, 2009 02:20 PM

There are a lot of interesting informations around here ...
Yet, I'm looking for your last flip flap code and I don't know where to download it.
May you indicate me an adress ?
Thanks in advance
Best regards

Posted by: Thierry on October 21, 2009 10:43 AM

hi mario

have any changes happened in Windows 7 and browser updates?
i am happy with my cheap HP notebook and 8GB RAM, only wish software (not only browsers and flash, but most importantly photoshop and such) would "just do it"! or "just use it - it's there", make use of all the memory i have.

did you see any improvements in that regard in W7 machines?


Posted by: Tomas Loewy on January 1, 2010 02:55 PM

Hi Tomas,

AFIAK you will have to install a 64bit version of Windows 7 in order to make full use of Memory over 4G


Posted by: Mario Klingemann on January 1, 2010 04:03 PM

Doesn't work without bugs....

Error: Error #1502: Een script wordt langer uitgevoerd dan de standaardperiode voor een time-out (15 seconden).
at memoryhog_fla::MainTimeline/updateStatus()
at memoryhog_fla::MainTimeline/grab100()

Can you send me an older version of it?
I have posted my e-mail.

Posted by: lonic on February 28, 2010 08:19 PM
Post a comment

Email Address:



Remember info?

Thank you!

Most Visited Entries
Sketches, Works & Source Code
In Love with
Powered by
Movable Type 2.661

© Copyright Mario Klingemann

Syndicate this site:
RSS 1.0 - RSS 2.0

Quasimondo @ flickr
Quasimondo @ LinkedIn
Quasimondo @ Twitter
Quasimondo @ Facebook
Quasimondo @ MySpace
Quasimondo is a Bright
Citizen of the TRansnational Republic
My other blog in german

My family name is written Klingemann,
not Klingelmann, Klingeman, Klingaman, Kingemann,
Kindermann, Killingaman, Klingman, Klingmann, Klingonman
Klingemman, Cleangerman, Klingerman or Kleangerman

profile for Quasimondo at Stack Overflow, Q&A for professional and enthusiast programmers