memory leak

I am new to BlitzMax, so I wanted to experiment with the garbage collection idea to make sure I understand how it works to avoid memory leaks. In my first basic example, there appears to be a memory leak.

SuperStrict

Type ta
	Field a%,b%,c%
End Type

Type tb
	Field a:ta
End Type

GCCollect()
Print "0 Objects: " + GCMemAlloced()

Local b:tb = New tb

GCCollect()
Print "1 Objects: " + GCMemAlloced()

b.a = New ta

GCCollect()
Print "2 Objects: " + GCMemAlloced()

b.a = Null  ' comment this for even more leakage, since b.a apparently isn't collected after b is collected below. Or maybe b isn't being collected at all?

GCCollect()
Print "1 Objects: " + GCMemAlloced()

b = Null

GCCollect()
Print "0 Objects: " + GCMemAlloced()

Strings are objects too.

Blitz GC is both I think incremental in nature and hard to predict at the best of times, that doesn't make it bad, it just makes it fast.

Also, putting your code in a loop shows it doesn't leak.

people are way to freaked out and misinformed about this leak stuff. there is no leak in your code above even if you comment out those lines. the GC in blitz does it's job as it sees fit at the time.... just because you call GCCollect yourself, it doesn't mean those things are ready for collection.

there are few reasons to null your variables at all in blitz. the ref counter will take care of this just find as it does in your code above. you really only have to null cyclic references.(when one object points to another and that object points back)

As skid said, put it in a loop....

SuperStrict

Graphics 800,600

Type ta
	Field a%,b%,c%
	Field big:Long[1000]
End Type

Type tb
	Field a:ta
End Type

Local b:tb = New tb
Local peakmem:Int

While Not KeyHit(KEY_ESCAPE)
	Cls
	b.a = New ta

	Local currentmem:Int = GCMemAlloced()
	If currentmem > peakmem Then peakmem = currentmem
	DrawText currentmem+" -> "+peakmem,10,10
	
	Flip
Wend

The GC in BlitzMax does take a little getting used to, but in my experience, it is rock solid.

"you really only have to null cyclic references. When one object points to another and that object points back"

Amen to that. :)

What I was trying to figure out when I first set up this test is whether I need to set object properties to null before the object itself is set to null (whether manually or automatically by falling out of scope).

The docs say that you still need to manually remove list items or they will never go away. Is this true? What if I have a list object as a property to another object that goes away? Does the list of objects still exist? Example:

type mytype
  field mylist:TList
end type

a:mytype = new mytype
a.mylist = new TList
ListAddLast a.mylist,"Something"

a = null  ' does this clean up the list and objects in it?

When the docs refer to list items, they mean items *in* a list. The list itself is marked for collection when the object it is in ceases to exist. I think it's just trying to make it clear that all the time you have a list with items in it, those items will not be collected.

An object will be marked for deletion when it is no longer in scope and not referred to by any other object.

It may not be cleaned up immediately, but it will eventually, when the garbage collector decides.

When a list is deleted, any items in the list will have their reference count lowered by 1. If that means that now no other objects refer to the item, it will also be marked for deletion... and so on.