Memory traps

18 posts

Flag Post

Are there any common beginner mistakes in AS3 which result in memory leaks?

 
Flag Post

Do you have a memory leak you’re trying to find and plug, or you’re just asking?

The garbage collector is fickle and you have no control over it. Fully de-reference everything you want collected. Don’t keep creating and destroying similar objects over and over, create a pool instead.

 
Flag Post
Originally posted by Ace_Blue:

Do you have a memory leak you’re trying to find and plug, or you’re just asking?

I’m just asking. The sooner you are aware of a problem the easier it is to fix it.

 
Flag Post

To clarify the “de-referencing” part, make sure to remove objects from the stage as well as any variable references to that object. Otherwise, the bullets that move offscreen and are supposed to go away when they do…will just to sit there and do nothing but take up space/memory/resources.

Also, make sure to manage any arrays by not only removing expired objects, but by compacting them down as well to close the gaps. Otherwise, the arrays will grow and grow and grow, even if most of their contents are null.

Like Ace said though, object pooling is good. As a new programmer, if you can wrap your head around the concept, it’s far more efficient than creating/destroying things constantly.

 
Flag Post

Understanding garbage collection in Flash Player 9

Though to answer your original question, I don’t know of any common mistakes that create serious memory leaks.

 
Flag Post

Most memory leak issues only apply to C++.

 
Flag Post

I’ve done it in Java; Minecraft modding. If you’re dumb and keep making new ModelBoxes every frame you can eventually memory leak the program.

 
Flag Post

Use weak event listeners?

 
Flag Post
Originally posted by feartehstickman:

Use weak event listeners?

According to this article weak referencing doesn’t work properly:

Along with nulling references, event listeners are also extremely “sticky” when it comes to making sure objects “stick” around. In my experience, using weak references doesn’t matter. If one object (Object A) subscribes one of its methods to an event on another object (Object B), then Object A and Object B will never be collected, and any objects they reference will also never be collected.
 
Flag Post

It’s my understanding that all weak referencing does is allow an object to be collected if no other references to it exist. The listener itself still remains and thus, is still wasting space.

 
Flag Post

Actually, from what I’ve tested it’s the opposite, the weak reference option is tied to the listener (the actual function object) not whatever the listener is attached to. Since class or static level functions can’t be scraped, this means it only becomes relevant when the function is stored in a variable or is anonymous. Which makes this whole option misleading and pointless to use in most cases (or not use, depending on how you look at it).

 
Flag Post

Ok then. Looks like weak listeners aren’t really worth using. I still remove as many as I can be sure of, it’s just in cases where I’d have to go if(something.hasEventListener(…))something.removeEventListener(…); 20 times. Maybe that’d be the best way to handle things though.

A way to globally remove all listener objects would be helpful though.

 
Flag Post
Originally posted by feartehstickman:

A way to globally remove all listener objects would be helpful though.

There exist classes for that. And you could probably write your own without much difficulty.

 
Flag Post

Ok, thanks. I’ve never looked too deeply at how Flash handles events, perhaps I should.

 
Flag Post
Originally posted by Tulrog:

Are there any common beginner mistakes in AS3 which result in memory leaks?

I’m guessing the most common thing would be event listeners and duplications. or any other /object/mc etc

 
Flag Post
Originally posted by Tulrog:
Originally posted by feartehstickman:

Use weak event listeners?

According to this article weak referencing doesn’t work properly:

Along with nulling references, event listeners are also extremely “sticky” when it comes to making sure objects “stick” around. In my experience, using weak references doesn’t matter. If one object (Object A) subscribes one of its methods to an event on another object (Object B), then Object A and Object B will never be collected, and any objects they reference will also never be collected.

There’s no code provided. Nobody knows what he was doing.
Objects will stick around, even if they should be collected, because having objects egliable for collection does not mean the collector runs.

 
Flag Post

I believe I read somewhere that it was possible to force the garbage collector to run. It should therefore be possible to do some tests…

Having done a little looking, it appears that in FP10 you could do something dodgy to get it to run, which may or may not still work. There is the System.gc() method which would force the garbage collector to run, but only in a debug flash player. Then in FP11, the System.pauseForGCIfCollectionImminent() method was added which allows you to effectively force garbage collection and works in all players. http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/System.html#pauseForGCIfCollectionImminent()

 
Flag Post

You shouldn’t need to force the garbage collector to run, if you’re in a situation where you’re allocating that much memory frame over frame, you might reconsider your approach. Others have mentioned pooling, and I would recommend this method especially for objects that need to be created and destroyed very frequently (such as bullets, particles, enemies, etc.).

The key to avoiding memory leaks is to remember that every time you invoke the new keyword, you are allocating memory. If you continue allocating memory but don’t release it, you have a memory leak.

So your options to avoid memory leaks are either pooling, or to make sure that the objects you create are properly de-referenced when you’re done with them, so they can be garbage collected. Personally, I prefer the pooling method— it takes a little more engineering up front, but it will benefit performance and lets you avoid having to rely on the garbage collector too much.

Pooling

The goal of pooling objects is to avoid having to constantly be creating and destroying new objects— also what’s known as memory churn. We want to reduce our memory churn. The whole process of creating a new object in memory takes processor cycles and if you’re not careful it opens you up to memory leak issues. The goal of pooling is to only invoke the new keyword once, when your program is initialized, and then re-use the same objects over and over. Each time you re-use the object, you don’t need to allocate memory for it, you just take it from your pool and reset its properties. When you’re done with it, you put it back in the pool.

De-referencing

If you can’t pool your objects (or in places where pooling doesn’t make sense, but you will need to free an object from memory), you’ll want a strategy to de-reference them properly so the GC can clean them up. Others have touched on this already so I’ll just mention what I tend to do. First make sure that it’s not on the display list (call removeChild), and also that no other objects or event listeners are referencing the object. Then you set the object’s reference to null (object = null). If it’s part of an array or other collection, remove it from the collection. At this point it should be good for garbage collection.