

Motherfucking AS3 Garbage Collection - archon810
http://www.andymoore.ca/2010/03/motherfucking-as3-garbage-collection/

======
gus_massa
The most interesting part is a link to
[http://tomgabob.blogspot.com/2009/11/as3-memory-
management.h...](http://tomgabob.blogspot.com/2009/11/as3-memory-
management.html) that has an explanation of the problem with this garbage
collector. I think you should submit it.

~~~
benologist
Pfft. The most interesting part is Andy's using my analytics system in the
game he's talking about. :)

~~~
Luc
Which analytics system is that? Sounds interesting.

~~~
benologist
<http://www.swfstats.com/>

If you want you can sign in to my account and see it in action on some of my
games, just drop me an email: ben at swfstats.

------
chipsy
I've only encountered "magic" with memory in AVM2 a few times - primarily,
where API allocations and object allocations interact. I usually blame myself
for it, but it's a problem rife throughout the Flash API that you'll try
something and it won't work because you did it before Flash was "ready," so
you have to go back and do some voodoo and defer things to run in just the
right order to get it to work. These quirky behaviors are left undefined in
the specs and docs.

I also don't use the fancy features of AS3 - Dictionary and weak references -
because I work from haXe and would rather write for portability most of the
time. And I minimize my use of the event listeners and display list for the
same reason. I think I've avoided a lot of grief because of that.

------
viraptor
The blog post he links makes me wonder... Is AS3 garbage collector a
compacting one? He wants to make his memory usage to be flat, not a saw shape,
but if the GC is not compacting, I wouldn't expect that to make a difference.
Especially that in most GC designs, by using object pools you'd be trading the
time it takes to update free area lists for the time GC spends going through
the tree (you've got more objects used on average, all referenced in a pool).

Am I missing something here?

~~~
barrkel
I can only think that the GC has a bug. From [1], the GC is incremental, but I
suspect it's not guaranteed to make forward progress, because it's not
collecting large orphaned object graphs.

Object pooling may or may not make sense depending on whether the GC is
generational or not, and how large the graph of live objects normally is. In a
non-generational GC, the whole object graph will need to be traced to free any
garbage at all, which means that if your live set of objects is large - and
hence expensive to trace - you'll want to minimize the number of allocations,
and pool almost as much as possible, especially if the GC is non-incremental
and users can perceive freezes during a GC.

In a generational GC, cheap objects should not be pooled, but it may make
sense to pool objects that are expensive to allocate or collect. For example,
in .NET large objects like long arrays (over 40K bytes IIRC) are allocated in
a special heap that's only collected with a full GC. Pooling those guys makes
a lot of sense, because dropping them as garbage will force full GCs too
often.

I would expect most modern GCs to be compacting (and generational), to avoid
fragmentation, the cost of keeping track of a free list and improve locality,
but if there's a lot of interop between the GC managed memory and native code,
then updating references may be problematic.

[1]
[http://192.150.8.60/devnet/flashplayer/articles/garbage_coll...](http://192.150.8.60/devnet/flashplayer/articles/garbage_collection.html)

~~~
chipsy
AVM2 is currently non-generational, so it benefits from pooling. This works
out just fine for Flash games, since you generally want games to have a highly
static data set anyway - otherwise performance is just all over the place.

AVM2 also has the "Alchemy memory" since Flash 10 which adds a whole new
option, independent of the GC, for tightening your space/time constraints:
<http://lab.polygonal.de/2010/03/15/memorymanager-revisited/>

------
Daniel_Newby
The pictures are great.

