Trusting the garbage collector

[Mekire]

Just ran into a case where the garbage collector is absolutely not doing what I need it to do.

Context: I'm creating a game hub from which users can enter a number of different mini games. The mini games may have their own resources which load when they are started up, but they need to release this memory when you exit back to the menu. My initial intuition was to kill all links to these resources so when the specific game instance goes out of scope the gc should reclaim the memory. This has unfortunately proved problematic. The resources do not get cleaned up quickly, and in fact if I exit and restart the mini game from the hub I can push the memory usage as high as I want... which is not good.

I have now added an explicit gc.collect call after a state flip and this gets the job done, but I do wonder why the automatic gc is being so unreliable. I would rather not have to resort to this.

[Larz60+]

Apparently if the allocated memory was used in a sub-process:
Answer 15 here: https://stackoverflow.com/questions/3216...le_rich_qa

[Mekire]

That is interesting. I'm definitely not going to go the route of making the mini games there own processes here but it could prove useful in the future. The explicit gc solution does work but it is a bit annoying to need to micromanage like that. Currently it is only called on state flip so it shouldn't particularly impact program flow.

[Larz60+]

It sounds kind of like Microsoft file detete, where they set a flag on the file
making it available for overwrite, but not physically clearing the memory and making
it immediately available again.

It would be interesting to examine the garbage collection process, and see what's actually
being done. I suspect that with proper precautions, there would be a way to 'pop' the memory
allocation completely off the allocation stack.