Comments on: Tamarin part III – Garbage Collector in Flash (10.0)

By: mm.cfg Secrets « Michael.Huang's Blog

mm.cfg Secrets « Michael.Huang's Blog — Sun, 15 May 2011 04:36:45 +0000

[...] DisableIncrementalGC = 1|0 Lets you enable/disable Garbage Collector Incremental policies (more info on the GC) [...]

By: New Flash Visual Profiler « jpauclair

New Flash Visual Profiler « jpauclair — Wed, 21 Apr 2010 02:50:42 +0000

[...] The flash GC doesn’t guarantee that all “dead” objects will be collected in a single p… But having those blue rectangle collected almost randomly is really fun to see. [...]

By: AS3 hidden treasure in the mm.cfg file. Revealing and documenting many Flash secrets! « jpauclair

Thu, 11 Feb 2010 05:01:15 +0000

[...] DisableIncrementalGC = 1|0 Lets you enable/disable Garbage Collector Incremental policies (more info on the GC) [...]

By: Nicolas

Nicolas — Tue, 05 Jan 2010 09:27:55 +0000

It’s indeed useful when you want to do “serious work” to understand the GC. But as you stated, there’s a whole unknown part of the Flash Player which is how the whole timeline and sprites are handled.

For one of our game projects, we had to rewrite the whole timeline player in haXe and with some reuse optimizations we were able to get more performances than native implementation…

By: Jackson Dunstan

Jackson Dunstan — Thu, 24 Dec 2009 08:12:10 +0000

I understand wanting to keep specific implementation out of the blog. That’s been my policy too. I was asking for some general ideas… and you’ve provided them! Thanks again for the article and for the followup ideas and conclusion. It certainly gives me a lot to think about both architecturally and as far as day-to-day practices go.

By: jpauclair

jpauclair — Thu, 24 Dec 2009 05:16:09 +0000

I prefer to keep specific implementation from my job out of this blog. I’m sure you can understand why.
But in general, since the GC is scanning the whole object range before sweeping plus doing finalization on certain objects (like String and XML Node etc.) it’s best to keep a minimum heap size and object number.
If you have dozens of thousands objects instantiated in your project, there is a good chance of having visible pause.
Preventing that can’t really be done with a “magic trick” and require a good engine architecture supporting optimized live object serialization to make the number of instance lower.
For most project, the real problem is coming from assets created on the timeline because we have no control over theses. We can’t tell FlashIDE to “re-use” a sprite that is created a lot of time. We can’t make “real” object pooling with the timeline.
I also forgot to conclude my post!
The GC of flash caused me a lot of problem in the past but it’s not because it’s bad. It’s just because we are doing very big application. Since we use a lot of visual object (sprites) in flash, there is often a LOT of memory added to the heap and the triggers are harder to manage because of the objects size.
For a game engine, having access to explicit collection can be great. But Adobe made a good call by making it conservative and hence accessible to a lot more people.

By: Jackson Dunstan

Jackson Dunstan — Wed, 23 Dec 2009 21:48:38 +0000

That was downright fascinating! I wonder: in your experience studying the GC and implementing real-time projects for it, what techniques would you recommend so as to avoid noticeable pauses due to GC? I’d especially be interested if the article was tailored to games, since you and I both develop Flash-based MMOs. In the meantime, I’ll keep reading these articles. Every one has been great! Keep up the good work!