Garbage collection and linked lists
Monkey Forums/Monkey Programming/Garbage collection and linked lists
| ||
Suppose I have created a "custom" linked list of TCreatures:Class TCreature Global gFirst:TCreature Global gLast:TCreature Field fPrevious:TCreature Field fNext:TCreature ' other methods and functions ' ... End I have a method to add a new object to the list. It will add that object as the new "gLast". I also have a method to remove an object from the list. Just like the adding function, it updates values for fNext and fPrevious where needed, removing the current object from the chain but keeping the chain whole. Now I am adding a function to the class to delete the whole list. I was thinking this: Function clearAll() gFirst = null gLast = null End Function Is it correct to assume that garbage collection will now (or at a later stage) remove the complete list of objects from memory? The fPrevious and fNext fields of individual objects are still pointing to each other; I have only removed the link to the start and end object. So I was wondering if this would really remove all objects (my guess is it will). Or should I first visit every object and set their previous and last pointers to null? |
| ||
| I doubt that will remove the chain at all. if the garbage collector works at is should even if you null the first and last there is still a reference to the first object from the next object as fPrevious etc. It's called cyclic reference so no it would not be removed. Mark added a clearList function in his Tlist for exactly that purpose. It iterates through the list and removes the references to each one at a time. I take it back. I don't know enough to make that conclusion. It seems that Mark nulls the List in monkey code by removing reference to the chain handle. in that case, you might be correct. |
| ||
| Hi, No, you don't need to null everything - all the GC's can handle cyclic data structures. |
| ||
| ah! That's news to me but good to know. |
| ||
| Good to put a confirmation to a previous assumption! Would be good to have a "gc do's and don'ts" chapter in manual...? |
| ||
| I second the gc do's and don'ts. Or a chapter on Memory Management in monkey and how does it work on each platform :) |
| ||
| Thanks very much for the answers! |
| ||
| all the GC's can handle cyclic data structures what does that mean? cause if your relying on the native GCs then what about ios which doesn't currently have one? |
| ||
| yes, how does it deal with deleting objects? ...what about ios which doesn't currently have one? Not exactly, if you are using the latest Xcode(4.2) which has IOS 5, it now uses ARC(Automatic Reference Counting) which supposedly is better than any GC.: http://developer.apple.com/technologies/ios5/ |
| ||
| Hi, Ok, just started on a memory management section for the language docs. It currently looks like this: Monkey is a garbage collected language, and depends on the underlying target language to provide memory management. Finalizers are not supported. If you need an object to be 'destroyable', you will need to add a 'Destroy' type method. The garbage collector is capable of collecting cyclic data structures such as linked lists automatically. The current C++ garbage collector will only collect garbage when control is returned to the OS. In the case of C++ Mojo targets such as IOS and GLFW, this occurs after any of the 'On' methods such as OnCreate, OnUpdate etc return. In general, the best way to use the garbage collector is to ignore it! Although such practices as 'nulling out' object references are common, they are seldom required. But it's a good idea to monitor your apps memory requirements as you develop anyway. This will allow you to catch any memory issues, GC related or otherwise, early on. Note that the iOS target uses the same custom C++ GC as GLFW. ARC looks interesting, but pretty complex. I have no plans to use it yet anyway - more info here for the curious: http://clang.llvm.org/docs/AutomaticReferenceCounting.html |
| ||
| Sounds good to me! |
| ||
| The current C++ garbage collector will only collect garbage when control is returned to the OS. In the case of C++ Mojo targets such as IOS and GLFW, this occurs after any of the 'On' methods such as OnCreate, OnUpdate etc return. So if I have more than 1 level and create them in the OnUpdate() method, when switching from Level 1 to Level 2 then memory of Level 1 will not get collected? How hard would it be to implent a BMax style GCCollect() function? |
| ||
| For java it should be as simple as wrapping System.gc() |
| ||
| So if I have more than 1 level and create them in the OnUpdate() method, when switching from Level 1 to Level 2 then memory of Level 1 will not get collected? Reading for comprehension fail. It depends on your implementation, but if "level1" becomes unreachable at the end of OnUpdate(), then yes it will be garbage collected. How hard would it be to implent a BMax style GCCollect() function? It would probably be trivial but equally pointless. The question you should be asking is how hard would it be to write your software within the constraints of the language you're using? For java it should be as simple as wrapping System.gc() Except you probably don't want to run the GC within the scope of the main threads ThreadLocal instance. You would probably just want the GC to run in a worker thread whenever the VM determines that it's running out of heap space. |
| ||
| I know, internally, the Monkey GC keeps track of memory in use. Would be helpful if this information could be available externally. When I was working on a couple features for my current app (i.e. Undo system and serializing/ encrypting of game save info), being able to see the memory-in-use stats as tracked by the GC, help me realize my initial approaches to both where too memory hungry and causing too many runtime-allocations. But I had to hack the Monkey sources a tiny bit to get at that GC information ... |
   |