Garbage Collection ?!

BlitzMax Forums/BlitzMax Beginners Area/Garbage Collection ?!

Trader3564(Posted 2008) [#1]
Ok, so the example below shows many things. And im confused because of it.

When i do not do GCCollect() blitzmax (in the docs) it tells me that it is called automaticly by BM... so i would expect to see the same nubers for S and E since Local would be local to the For Next loop right?
Yet i only see an increase.

(p.s. do not forget to uncommect the 3 'local' lines with the image stuff, but even with the lines commented, you see an increase ?!? ... of what?)

Ok, now move these lines to the function.
Seems there is no change.

BM docs tell me that ON RETURN of a function, locals are collected. So i tought that maybe i need to actualy RETURN something. Uncomment 'Return to test.
But this doesnt have any effect (as i hoped... since END FUNCTION should behave the same way as RETURN except it returns nothing, but we still want garbage to be collected, and not have to call Return just for that.)

Ok, now try uncommenting the GCCollect. You will see that you get nice numbers all matching up. But then i realised. The whole purpose of this example was to find out, how exacly i should treat variables, types, and objects to free memory when i dont use m anymore. So whats the point of having an automatic GC, when you need to manaly call it anyway?

When do i need to Variable = NULL things out. When to use a FreeMem or Unload command (for if there are any) When do i use Release, and do i need to NULL all local's inside a function or loop? And, is free'ing memory intensive? e.g. would i notice a drop in FPS?

Im not doing much fancy stuff, so memory is not cricital or even important. FPS is important. Yet, i do not want any memory leakes.

Anyone can give some clear insight in this matter? :)

Local I:Int

'GCCollect()
Print "S: " + GCMemAlloced()

For I = 0 To 10 

	Print "1: " + GCMemAlloced()
	'Local image:TImage = LoadImage("..\water.png") 
	'Local width = ImageWidth(image) 
	'Local height = ImageHeight(image)
	'image=Null
	Print "2: " + GCMemAlloced()
	
	
	'GCCollect()
	Print "3: " + GCMemAlloced()
	
Next

'GCCollect()
Print "E: " + GCMemAlloced()


Function test()
	'Return
End Function


-edit-
Ah.. and i wondered if the way the GC treats functions, is the same way as it treats methods?


tonyg(Posted 2008) [#2]
An object is made available for collecting when the last remaining pointer to it goes out of scope or is nulled.
I believe there is some 'objects to release' count which dictates when GC is run 500?) so, in your code, GC will not run.
Print creates an object internally so always makes things look odd.
Try the same code bu use a large counter or a while/wend loop and you should see the GC numbers cycling.


Otus(Posted 2008) [#3]
Also, GC works a bit different in debug mode, so you should use release, if you need to know how actual memory use will look...


dmaz(Posted 2008) [#4]
don't collect it yourself and stop worrying about it...

really, the only time you do need to worry is when you have cyclic references. if you do, then just null one to break the circle.