AS3 - when does the garbage collector start?

Question

apologies if this is a hoax; I could not find him.

I read and understood the skin skins blog in the AS3 garbage collector - http://www.adobe.ca/devnet/flashplayer/articles/garbage_collection.html , but my question is not addressed here.

here is my question.

Suppose I wrote some AS3 code, for example:

statementOne; statementTwo; 

Is there a chance that the garbage collector will work during or between my two statements or will only be executed after my "user" code is completed and the control returns to flash?

we have an A-Star code block, which is sometimes slow, and I would like to exclude GC as a potential culprit. the code block is obviously more complex than my example above, but this is not related to events or other asynchronous things.

TIA, Orion

Answer 1

There are many good answers here, but I think a few subtleties have not been considered.

• Flash player implements two types of garbage collection. One of them is link counting, where Flash stores the number of incoming links to each object and knows that when the counter reaches zero, the object can be freed. The second method is markup, where Flash sometimes searches for and removes isolated groups of objects (where objects link to each other, but the group as a whole has no inbound links).
• Depending on the specification, any kind of garbage collection can occur at any time. The player does not guarantee when objects will be released, and marks can be scattered over several frames. In addition, there is no guarantee that the GC time will remain the same between Flash player versions or platforms or even browsers. Therefore, in a sense, it’s not very useful to know anything about how GC starts, since you cannot find out how widely your knowledge is applicable.
• In the previous paragraph, generally speaking, markups are not uncommon and only work under certain circumstances. I know some player / OS configurations where a marker / sweep can start every N seconds or when a player has exceeded P% of the total available memory, but that was a long time ago and the details will be changed. On the other hand, counting counting GCs can occur frequently - between frames, at least. I don’t think I saw them being shown more often, but that doesn’t mean that this cannot happen (at least in certain situations).

Finally, a word about your specific problem: in my experience, it is very unlikely that the GC has anything to do with your performance issue. GC-processed GC processing may very well happen during your cycles, but this is usually a good thing - this collection is very fast and allows you to use memory. The whole point of carefully managing your links is to ensure that this kind of GC happens on time.

On the other hand, if a label / sweep appears during cycles, this will certainly affect your performance. But it is relatively difficult to make mistakes and easy to verify. If you are testing on a PC and your application does not regularly go up to hundreds of MB of memory usage (test with System.totalMemory ), you probably do not get any marks / scans at all. If you have them, it should be easy to make sure that the associated pauses are large, infrequent, and always accompanied by a large drop in memory usage. If these things are wrong, you can ignore the idea that the GC is part of your problems.

Answer 2

The garbage collector has no thread, so, generally speaking, it will not work while your code is running. However, there is one exceptional case where this is not true.

The new keyword will call the garbage collector if it runs out of memory.

You can run this code to observe this behavior:

 var vec:Vector.<*> = new Vector.<*>(9001); for (;;) { vec[0] = new Vector.<*>(9001); vec = vec[0]; } 

Memory usage will quickly rise to the maximum (1 GB for me), then hold it until the time is turned off.

Answer 3

As far as I know, this is not documented. I have a feeling that the GC will not work during the execution of your code (i.e., while your code is on the execution stack, each frame, the player creates a new stack to use the code). Obviously, this comes from observation and my own experience with Flash, so I would not say that it is 100% accurate. I hope this is a reasonable guess.

Here is a simple test that seems to show that this is true:

 package { import flash.display.Sprite; import flash.net.FileReference; import flash.system.System; import flash.utils.Dictionary; import flash.utils.setTimeout; public class test extends Sprite { private var _dict:Dictionary = new Dictionary(true); public function test() { testGC(); setTimeout(function():void { traceCount(); },2000); } private function testGC():void { var fileRef:FileReference; for(var i:int = 0; i < 100; i++) { fileRef = new FileReference(); _dict[fileRef] = true; traceCount(); System.gc(); } } private function traceCount():void { var count:int = 0; for(var i:* in _dict) { count++; } trace(count); } } } 

GC seems especially greedy when there are FileReference objects (again, this is from my experience, this is not documented as far as I know).

Now, if you run the above code, even explicitly calling System.gc() , the objects will not be collected while your function is on the stack: you can see that they are still alive, looking at the dictionary count (which to use for obvious reasons for weak links).

When this counter is traced again, in another execution stack (called by the asynchronous call to setTimeout), all objects were freed.

So, I would say that the GC is not the culprit of the poor work in your case. Again, this is a simple observation and the fact that the GC did not start while the user code was running in this test does not mean that it will never be. This is probably not, but since it is not documented, I do not know, for sure, for sure. Hope this helps.

Answer 4

GC will not work between two statements that are on the same stack / same frame as in your example. The memory will be freed until the next frame. This is how most modern VM environments work.

Answer 5

You cannot determine when the GC will work. If you are trying to stop something from GC'd, keep a link to it somewhere.

Answer 6

According to this Tom from Gabob , sufficiently large orphaned hierarchies do not receive garbage collected.