Releasing Memory
BlitzMax Forums/BlitzMax Beginners Area/Releasing Memory
| ||
| Hi, if I have for example the following code: type TObject field image:Timage[10] field x,y ...etc endtype global newObject:TObject newObject = new TObject Now say I wanted to delete newObject and release the memory of the object, I have been doing the following: newObject = Null ...and I have been assuming that any fields within the type would release their memory as well. But I have noticed that some code examplesI have encountered would first set all the images[] to null and then set newObject to Null. Is its best to null the elements of a type and then the type or doesnt it matter? Thanks |
| ||
| It doesnt realy matter, the GC should take care of any reference that goes out of scope automaticly. You only need to set a variable to Null if you want it to be taken care of at the next GCCollect() or if there is circular references, and even then its not garantied it will be freed at the exact spot you want it to be (although it will be eventualy ;) |
| ||
| grable: That is a very dangerous way you propose. As a mather of facts the BM GC does NOT have root references! This means the GC can not say if an object is linked to the root of the system at all. So if you NULLify the link to a cyclic double linked list for example, the list will NOT be removed by GC! You should always NULLify all the objects you have within your own objects. To do so, simply override the delete method and you won't have to care for that anymore. If you do not do that, you might risk that stuff is not removed. |
| ||
| Realy??.. if this is true, i have some major code restructuring on my hands :( |
| ||
| Isn't it enough to add method delete() to all the classes where you nullify its subparts? (delete() is called by the GC when an object is removed, at least as long as the object is deleted before the OnEnd event which happens when you use end or a user quits it) |
| ||
| Hmm.. id think so.. Usaly i have Clear() or Close() methods that i call from Delete() that cleans up any kind lists. I did some tests by adding a counter do New() and Delete() .. so far no objects are removed at the end of my program :( even when i ecplicitly call Clear() and set its ref to Null and call GCCollect() then print the numbers before the end. I realy hope its just me, havent slept in 2 days ;) |
| ||
| If thats the case, doesnt that mean that you'd have to nullify all the fields of the type including ints. floats, strings as well as images/sounds etc? |
| ||
| Ant: no, the GC only deals with Object references. |
| ||
| What type of structure do your object have? Perhaps its a simple back-reference issue that is causing the problem or so which can be solved by a simple "clean splitting" (ie parent starts cleaning, then calls the childs clean function and then finish its own cleaning which depended on the child beeing nullified before, for example) |
| ||
| Its a LISP evaluator im working on Type TCell Field CAR:TCell Field CDR:TCell EndType its basicly a linked list structure, eg lists in lists in lists hehe. It could be that i have a global instance of TCell that acts as a common Nil (Null) to all TCell's.. i dunno btw. does this mean i have manually null over arrays too? |
| ||
| I just answered by own question ;) that global instance realy did mess things up, damn. the whole design of the evalutor is baes around that point LOL. Thanks for letting me know Dreamora =) this might solve the speed issue ive been having as well. |
| ||
| Happy that it helped :-) Yeah the chance that something like this leads to speed drops is there. There is another thing that might help: If you create a lot of objects within a function that are only needed within this function, it might help to speed up as well if you call GCCollect at the end of the function manually. |
| ||
| Just to bad this brakes my LISP thingy to pieces. The global instances referenced itself to avoid possible errors of using NIL itself as a list. |
| ||
| Dreamora - thanks for the help, grable - sorry I messed up your afternoon ;-( |
| ||
| Ant: hehehe.. no worries, it was a bad idea from the start. i was being lazy and now i have to pay for it ;) EDIT: yoho.. i got it to work like it was supposed to =) .. the speed only went up a tiny fraction though :/ |
   |