Not calling the garbage collector.....
Ok I have a question. I have a game that I have been running for days on end. Basically, I load a script for a level, run it and when the game is over I unload that script. Then to play another level, the game loads and runs a different level script and then unloads it when the level is done. This is done continuously.
The scripts merely access C++ CHuman class objects that are instantiated in the actual C++ code. The scripts in no way can dynamically create CHuman objects and they also do not free them from within the script. Creation and deletion of these objects is left to the C++ game code. The scripts at most can request that the C++ game code instantiate a CHuman object on their behalf.
My question is this. I NEVER call the garbage collector while the game is continuously running for several days. What are the consequences\repercussions\impact of not doing this given what I have described above?
Thanks for anyone's help
Hatori
AngelScript's memory management is based on reference counting, with a garbage collector for resolving cyclic references. If no objects that can produce cyclic references are declared then the garbage collector will never be used, and there is no need to invoke it.
It can however be difficult to control the declarations that script writers do, so I suggest you add a call to the garbage collector at least once in a while. For example when you're doing other time consuming tasks anyway, such as loading resources or compiling scripts.
I also suggest you monitor the number of objects in the garbage collector with engine->GetGCStatistics so you can have the application take appropriate actions if any badly designed scripts accumulate a lot of garbage.
Regards,
Andreas
It can however be difficult to control the declarations that script writers do, so I suggest you add a call to the garbage collector at least once in a while. For example when you're doing other time consuming tasks anyway, such as loading resources or compiling scripts.
I also suggest you monitor the number of objects in the garbage collector with engine->GetGCStatistics so you can have the application take appropriate actions if any badly designed scripts accumulate a lot of garbage.
Regards,
Andreas
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game
Ok I have used GetCSStatistics as you suggest on my game. The parameters to this function are:
currentSize current number of objects known to the garbage collector.
totalDestroyed total number of objects destroyed by the garbage collector.
totalDetected total number of objects detected as garbage with circular
references.
In my game currentSize keeps growing as I run more and more scripts. totalDestroyed and totalDetected stay at zero. Now my question is what does angelscript do with these objects that are known to the garbage collector? Does it keep them around for the duration of the executable? As time goes by does the overhead of tracking all these objects increase in respect to both memory and CPU usage?
Thanks for your reply,
Hatori
currentSize current number of objects known to the garbage collector.
totalDestroyed total number of objects destroyed by the garbage collector.
totalDetected total number of objects detected as garbage with circular
references.
In my game currentSize keeps growing as I run more and more scripts. totalDestroyed and totalDetected stay at zero. Now my question is what does angelscript do with these objects that are known to the garbage collector? Does it keep them around for the duration of the executable? As time goes by does the overhead of tracking all these objects increase in respect to both memory and CPU usage?
Thanks for your reply,
Hatori
If the number of objects in the garbage collector goes up, then you really need to add calls to the garbage collector at appropriate times to free them. If you never call the garbage collector to clean up the objects, you'll eventually run out of memory.
The number of objects in the garbage collector doesn't affect the processing as the garbage collector doesn't do anything unless you explicitly call it. Obviously the more objects there are in the garbage collector the longer it will take for the garbage collector to process it all when you do call it.
However, you can spread out the processing of the garbage collector by running it with incremental steps. That way you can do a little processing each frame, without risking getting noticeable halts in the responsiveness.
The number of objects in the garbage collector doesn't affect the processing as the garbage collector doesn't do anything unless you explicitly call it. Obviously the more objects there are in the garbage collector the longer it will take for the garbage collector to process it all when you do call it.
However, you can spread out the processing of the garbage collector by running it with incremental steps. That way you can do a little processing each frame, without risking getting noticeable halts in the responsiveness.
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement