How to free up memory and destroy Array, is it ok to do just like this
myarr = null
myarr = new Array
is all the old content of myarr now freed from memory?
Assuming you haven't got another reference to the array in another variable somewhere the arrays memory will be recovered when the GC gets to it.
If there are no more references to that Array Object, then it is collected by the Garbage Collection (GC) system. So when you ask "is all the old content of myarr now freed from memory?", the answer is it could be. But you have no control over when the GC runs using the Actionscript Virtual Machine.
So it is true to say, when there are no more references to an object, the next time the Garbage Collector runs, it will be collected.
Also things get more complex when you are dealing with a Array. The Array object might be collected, but that does not mean that the objects the Array references will be cleaned up too. The objects the Array references might be one of many references to those objects, for instance maybe a copy of that Array exists in your system, meaning at least two references exist to each object in each Array.
Also be aware that event listeners stop objects from being Garbage Collected, unless they are weak event listeners
myarr = nothing
Garbage Collection in .Net would sort this anyway. Thats if your in .NET.
Related
Are there any general guide lines for using retain and release for objects in cocos2d-X ? When creating objects in a function, is it true that the functions memory is cleaned up the second the function returns. When a object is created, calling the retain function of the object, will retain object beyond the function return ?
Kind Regards
Generally in c++ you have this behaviour:
void foo() {
Object a;
Object *pA = new Object();
(…)
}
This would result in a being destroyed automatically at function end, as it was allocated on stack. The *pA would not get destroyed, as it was allocated on the heap (thus, you only loose the reference to it, but the object itself still lives).
Cocos implements a thing called "Automatic Reference Counting" : each CCObject has a reference counter and two methods retain() and release(). The way this works is, that every time you create an object, it gets registered in cocos structers (CCPoolManager). Then with every frame (between them being drawn) there is a maintenance loop which checks the reference counter of all objects : if it is 0 this means (to cocos) that no other objects reference it, so it is safe to delete it. The retain count of an object is automatically incresead when you use this object as an argument for an addChild function.
Example :
void cocosFoo() {
CCSprite *a = CCSprite::create(…);
CCSprite *b = CCSprite::create(…);
this->addChild(b);
}
What happens here is this :
Two CCSprites are created, cocos knows about them.
The b sprite is added to this object (say a CCLayer)
The function ends, no objects are destroyed (both of them being on heap).
Somewhere between this and next frame, the maintanance gets run. Cocos chcecks both sprites and sees that a has reference count == 0, so it deletes it.
This system is quite good, as you don't need to worry about memory management. If you want to create a CCSprite (for example), but not add it as a child yet, you can call retain() on it, which will raise its reference counter, saving it from automatic deletion. But then you'd have to remember about calling release() on it (for example, when adding it as a child).
The general things you have to remeber about are :
Each call to retain() by you needs to be paired with release().
You generally shouldn't delete CCObjects yourself. If you feel that you need to, there is a conveniece macro : CC_SAFE_DELETE(object)
So to answer your questions in short :
Are there any general guide lines for using retain and release for objects in cocos2d-X ?
Yes, you should generally not need to do it.
When creating objects in a function, is it true that the functions memory is cleaned up the second the function returns.
Answer to this is the whole text above.
When a object is created, calling the retain function of the object, will retain object beyond the function return ?
Yes, as will adding it as a child to another (retained in any way) object.
Here is the thing,
cocos2dx has an autorelease pool which drains the objects which have retain count=0 which is a variable to keep in check the scope of the cocos2dx object.
Now when you create new object using the create method it is already added to the autorelease pool and you don't need to release it or delete it anywhere , its like garbage collector in java, takes care of garbage objects behind your back.
But when you create new object using 'new' you definitely need to release it in its destructor or after its use is over.
Second thing,
when your object is added to the autorelease pool but you need it somewhere else you could just retain it , this increments its retain count by one and then you have to manually release it after its use is over.
Third Thing,
Whenever you add child your object it is retained automatically but you don't need to release it rather you remove it from the parent.
I have these three objects that i need to add on stage, when I extract them from the array on a later stage of the program.
I can't write var mall: Mall = new Mall (); because somebody told me before that, This will add in the object in the memory and will be really bad if a lot of objects are being handled. I will have a lot more objects to work with later on.
So I would like to know a way that when i run a for loop or an event listener i can add ... = new object (); automatically and then call addchild to make an instance of the object.
var mall:Mall;
var library:Library;
var music:Music;
var choices:Array = new Array ();
choices.push(mall,library,music);
test Code for Garbage Collection :
var waking: WakingUp = new WakingUp ();
addChild (waking);
waking.y=-30;
waking.addEventListener (Event.ENTER_FRAME, waking_up);
function waking_up (g:Event){
if (waking.currentFrame == waking.totalFrames)
{
waking.stop ();
waking.removeEventListener (Event.ENTER_FRAME,waking_up);
removeChild (waking);
removeChild(alarm_slide);
gotoAndStop (6);
}
}
This is all the ref I have to this code :D
Specific to instantiating your array with elements, you can:
var choices:Array = [ mall, library, music ];
Flash Player runtime uses both reference counting as well as mark and sweep.
So, any reference to the instance adds a count - collections, display list, event listeners, class members... as instances are dereferenced, the memory will ultimately be freed.
Reference Counting
Each object on the heap keeps track of the number of things pointing to it. Each time you create a reference to an object, the
object's reference count is incremented. When you delete a reference,
the object's reference count is decremented. If the object has a zero
reference count (nothing is pointing to it), it is added to the Zero
Count Table (ZCT). When the ZCT is full, the stack is scanned to find
any references from the stack to an object on the ZCT. Any object on
the ZCT without a stack reference is deleted.
One of the problems of deferred reference counting is circular references. If ObjectA and ObjectB refer to each other but no other
objects in the system point to them, they will never have a zero
reference count and will therefore never be eligible for garbage
collection using reference counting. This is where mark and sweep
garbage collection helps.
Mark/Sweep
Applications that run in Flash Player or AIR have multiple GCRoots.
You can think about a GCRoot as the trunk of a tree with the objects
of the application as the branches. The Stage is a GCRoot. Loaders are
GCRoots. Certain menus are GCRoots. Every object that is still in use
by the application is reachable from one of the GCRoots within the
application. GCRoots are never garbage collected.
Every object in an application has a "mark bit." When the Mark phase
of garbage collection begins, all of those mark bits are cleared. The
MMgc keeps track of all GCRoots in the application. The garbage
collector starts from those roots, traces through each object and sets
the mark bit for every object it reaches. Any object that is no longer
reachable from any of the roots is no longer reachable from anywhere
in the application – its mark bit does not get set during the Mark
phase. Once the collector is done marking all of the objects it finds,
the Sweep phase begins. Any object that doesn't have a set mark bit is
destroyed and its memory reclaimed.
addChild does not make an instance of the object, it simply adds the object to the displaylist of the current display container.
Using new Mall() is fine - just ensure that you remove references to it when it's no longer required so that it may be garbage collected. Alternatively you can just hold an array of primitives.
I'm using AS3 and FlashDevelop, and I cannot seem to convince my FlashPlayer/AVM to GC it.
I tried the pretty standard options:
myboolean = null;
delete(myboolean);
But for the null it says "col: 14 Warning: null used where a Boolean value was expected."
And delete I get "col: 11 Error: Attempt to delete the fixed property allDone. Only dynamically defined properties can be deleted."
And this is considering the Boolean is definited within a method as such:
var myBoolean:Boolean = false;
I appreciate that since it's within the method, when such has run it's course it should get garbage collected, but I like to be certain, and why can't I GC the Boolean when I've done the same for int, Array and Point within another method of the same class? Isn't Boolean also an object?
So if anyone knows how to GC the Boolean please let me know.
Basically like Jonatan Hedborg here says you don't directly control what is garbage collected.
My guess is you're from a c/c++ background or the like where you are responsible for maintaining memory more strictly and directly, this isn't exactly the case with AS3 and Java; though memory management is still very important it's handled more at an Object level. Although Boolean extends from Object read here regarding primitive types:
Null data type The Null data type contains only one value, null . This
is the default value for the String data type and all classes that
define complex data types, including the Object class. None of the
other primitive data types, such as Boolean, Number, int and uint,
contain the value null . Flash Player and Adobe AIR will convert the
value null to the appropriate default value if you attempt to assign
null to variables of type Boolean, Number, int, or uint. You cannot
use this data type as a type annotation.
http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7f88.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7f82
In both cases you do have mechanisms such as nulling references to detach objects from the graph of all of the active objects which means they'll be garbage collected at the next scheduled run of the garbage collector (which can be forced but it isn't really recommended, the configuration for the JVM or AVM in this case will handle it based on the system it's running/executing in).
nulling an object will allow it to be garbage collected but you shouldn't really be concerned about individual primitive properties. There's a good article explaining some details on garbage collection in AS3 here (I would leave a an abstract but the whole page is pretty good, main points I suppose being garbage collection isn't necessarily 100% straight-forward but with some effort can be managed):
http://tomgabob.blogspot.com/2009/11/as3-memory-management.html
Basically the way it works is the FlashPlayer or whatever virtual machine is running your (byte)code has a graph of all the objects that have been created and that there is a current reference to.
It also has a memory limit for what it can use based on the environment (config etc.) so the GC has algorithms setup to figure out when it should attempt to garbage collect. You should primarily be concerned with nulling references to objects you no longer need, and really this isn't too big of a deal if your application isn't fairly complex, or your hardware isn't extremely restrictive with regard to RAM.
So the concern shouldn't be making the GC run too little or too much, but creating references that are never removed (addingListeners and not removing from objects that should be collected, or simply having references to them within collections etc. after they are no longer needed). Again the article above explains this in a bit more depth.
Where are you using the boolean? The only way to make sure primitives are GC'ed is to ensure the class it's used in is collected.
There are 2 errors in your reasoning:
'delete' can only be applied to dynamic objects, not class members or local variables; in these cases, just set the member/variable to null,
value types (boolean, number, string) don't need to be GC'd; in some cases Flash will create temporary 'boxing objects' which will be automatically collected so you don't have to worry about those.
Riddle me this: I have my MouseEvent.MOUSE_DOWN which calls mouseHandler. The latter looks something like this:
public function mouseHandler(evt:MouseEvent):void
{
var p:Point = new Point(mouseX, mouseY);
var objs:Array = new Array(getObjectsUnderPoint(p));
}
Now what I want to know is thusly: will the objs array and p point be overwritten every time, simply causing the previous objs array and p point to be wiped and a new one generated, or...does it just create a new array and point over and over and over? Of course if I trace(objs) it gives me the expected results, but am I chocking up the system in the background without realising? Your expertise would be appreciated.
EDIT: well after learning a fair bit from the answerers -thanks btw- that made me think of something else and, a quick search later, found a way to theoretically reliably remove the references:
var a = null;
Now I appreciate that this is probably not needed as they'll be GCed at the end of the function, but considering it takes two ticks to write, better safe than sorry, no?
It works like this from what I understand - references for these variables will be lost after function will end. The values will be GC'ed then eventually.
If you will call the function second time, the new references will be created, and filled with new data, the values of previous references hovewer, may still exist in memory, and wait for Garbage Collector, but that may not necessarily happen! If they have attached listeners, the Flash Player will think that they are still useful, so they will exist in the memory to the end of the application run and listen, and even react to events - even if you theoretically cannot access them anymore.
Edit:
In your case whats happening is that you are creating two references that will disappear at the end of the function. They are not related to event listener, the listener creates them, but is not attached to them so it won't stop GC from collecting them after function will end. You creates an array of references, but that are just references to other objects that values are referred in other places (like the display list), if the array alone is not referred anywhere outside of this function, it should be GCted.
Since p is an object, not a primitive, the memory allocation for it will come from the Heap (and therefore need to be garbage collected) instead of the stack like local primitives (and are wiped once the function ends.
So new memory will be allocated every time this function is called, which will temporarily increase memory usage until they get GC'd, but the amount is probably insignificant (assuming that array isn't massive!).
I have a lot of display objects in an array that I'm constantly adding and removing from stage. When removed they are not used anymore.
Considering the displayObject is not on the display list, and has no event listeners... will it be garbage collected if I use splice to remove it from the array?
Is it safer if I null the object first?
myArray[2] = null;
myArray.splice(2,1);
As long as there are no remaining references to the DisplayObject then yes, removing it from the array using splice, or even just setting it to null will allow it to become a candidate for garbage collection.
Update: Setting the item to null before removal from the array is redundant and will make no difference.
If you need better performance I suggest you using pools instead of creating lots of objects and putting them in array. Use some linked list implementation instead of splice() operation, which is really slow.