4 ms·

Motherfucking AS3 Garbage Collection

21 points by archon810 17y ago

gus_massa 17y ago
The most interesting part is a link to http://tomgabob.blogspot.com/2009/11/as3-memory-management.html http://tomgabob.blogspot.com/2009/11/as3-memory-management.h... that has an explanation of the problem with this garbage collector. I think you should submit it.
- epochwolf 17y ago
  I submitted it: http://news.ycombinator.com/item?id=1224646 http://news.ycombinator.com/item?id=1224646
- benologist 17y ago
  Pfft. The most interesting part is Andy's using my analytics system in the game he's talking about. :)
  - Luc 17y ago
    Which analytics system is that? Sounds interesting.
    - benologist 17y ago
      http://www.swfstats.com/ 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.
viraptor 17y ago
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?
- Confusion 17y ago
  From http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html http://www.adobe.com/devnet/flashplayer/articles/garbage_col... I gather that the GC isn't compacting, but I'm not at home in GC terminology, so perhaps it is, but they use another term for it.
- barrkel 17y ago
  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_collection.html http://192.150.8.60/devnet/flashplayer/articles/garbage_coll...
  - chipsy 17y ago
    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/ http://lab.polygonal.de/2010/03/15/memorymanager-revisited/
chipsy 17y ago
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.
Daniel_Newby 17y ago
The pictures are great.

21 points by archon810 17y ago

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

epochwolf 17y ago
I submitted it: http://news.ycombinator.com/item?id=1224646 http://news.ycombinator.com/item?id=1224646
benologist 17y ago
Pfft. The most interesting part is Andy's using my analytics system in the game he's talking about. :)
- Luc 17y ago
  Which analytics system is that? Sounds interesting.
  - benologist 17y ago
    http://www.swfstats.com/ 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.

viraptor 17y ago

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?

Confusion 17y ago
From http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html http://www.adobe.com/devnet/flashplayer/articles/garbage_col... I gather that the GC isn't compacting, but I'm not at home in GC terminology, so perhaps it is, but they use another term for it.
barrkel 17y ago
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_collection.html http://192.150.8.60/devnet/flashplayer/articles/garbage_coll...
- chipsy 17y ago
  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/ http://lab.polygonal.de/2010/03/15/memorymanager-revisited/

chipsy 17y ago

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.

Daniel_Newby 17y ago

The pictures are great.