Strange GC Reaction (Debug/non-Debug differ)

BlitzMax Forums/BlitzMax Beginners Area/Strange GC Reaction (Debug/non-Debug differ)

Kernle 32DLL

(Posted 2009) [#1]

Hi there again. Today, i step before you with a rather complicated problem. Searching my in-construction engine for memory leaks, i detected a strange thing about the GC. If i ran my app with DebugMode on, i always had 24Bytes uncleaned, wich would magicly disappear if i ran the app in Non-Debug Mode. Searching for the source of this problem, i created the following little 4 Experiments. Please tell me what you think. You'll find further description in the code.

SuperStrict

Type TestType
	Field Name:String
	
	Function Create(Name:String) 
		Local Instance:TestType = New TestType
		
		Instance.Name = Name
	End Function
	
	Function Create2:TestType(Name:String) 
		Local Instance:TestType = New TestType
		
		Instance.Name = Name
		
		Return Instance
	End Function
	
	Method Remove() 
		GCCollect()
	End Method
End Type

Print ""
Print "---------------------" 'clearline for the experiment
Print ""

'-------------------
'Experiment 1
'-------------------

GCCollect() 
Print "StartMemory: " + GCMemAlloced()

TestType.Create("Hugo") 

'IMPORTANT:
'doing a second GCCollect() here will solve the problem described below
GCCollect() 
Print "ProveMemory: " + GCMemAlloced() 

Rem
	DESCR:
		Creating an instance. Create does NOT return anything,
		so its not possible to ever access any object created
		with this function.
	DEBUG:
		StartMemory and ProveMemory are the same
	NON-DEBUG:
		ProveMemory is bigger than StartMemory, proving
		that our "Hugo" instance has not been killed yet.
		Question: Why? There is no possible way to access
		it anymore, it there?
EndRem

Print ""
Print "---------------------" 'clearline for the experiment
Print ""

'-------------------
'Experiment 2
'-------------------

GCCollect()
Print "StartMemory: " + GCMemAlloced()

TestType.Create2("Hans")

'IMPORTANT:
'doing a second GCCollect() here will solve the problem described below
GCCollect()
Print "ProveMemory: " + GCMemAlloced() 

Rem
	DESCR:
		Creating an instance. Create2 DOES return the instance.
	DEBUG & NON-DEBUG:
		ProveMemory is bigger than StartMemory, proving
		that our "Hans" instance has not been killed yet.
		Question: Why? There is no possible way to access
		it >anymore<, it there?
EndRem

Print ""
Print "---------------------" 'clearline for the experiment
Print ""

'-------------------
'Experiment 3
'-------------------

GCCollect() 
Print "StartMemory: " + GCMemAlloced()

TestType.Create2("Ralf").Remove()

'IMPORTANT:
'note that a second GCCollect() here WONT help
GCCollect() 
Print "ProveMemory: " + GCMemAlloced() 

Rem
	DESCR:
		Creating an instance, and killing at with the returned instance
	DEBUG:
		ProveMemory is bigger than StartMemory, proving
		that our "Ralf" instance has not been killed yet.
		Question: Why? There is no possible way to access
		it anymore, it there?
	NON-DEBUG:
		StartMemory and ProveMemory are the same
EndRem

Print ""
Print "---------------------" 'clearline for the experiment
Print ""

'-------------------
'Experiment 4
'-------------------

GCCollect() 
Print "StartMemory: " + GCMemAlloced()

Print TestType.Create2("Herbert").Name

'IMPORTANT:
'note that a second GCCollect() here WONT help
GCCollect() 
Print "ProveMemory: " + GCMemAlloced() 

Rem
	DESCR:
		Creating an instance, and print'ing by its returned instance
	DEBUG & NON-DEBUG:
		StartMemory and ProveMemory are the same

	WARNING:
		If you delete the whole Experiment 3 out of this sourcefile,
		Experiment 4 will react the same way like Experiment 3.
EndRem

Print ""
Print "---------------------" 'clearline for the experiment
Print ""

I'm really confused.... Not only does the Debug / Non-Debug thing look really strange to me, but so does the fact that the "problems" described in Experiment 1 & 2 can be solved by writing a second GCCollect() at the designated position in code.

So long,
Kernle

plash

(Posted 2009) [#2]

So you're saying 24 bytes of memory would always be present in debug mode, but not in release mode?
That's probably just the overhead data that debug mode uses.. for debugging stuff.

I wouldn't worry about it, 24 bytes isn't going to kill anything.

N	(Posted 2009) [#3]

I'm not entirely sure what you're reporting. The descriptions don't actually describe any bugs, and you don't say what the problem is, but there's certainly one odd thing about your code. In the TestType#Remove method, why are you calling GCCollect? The object isn't going to be collected when it's still in scope, so what's the point?

Also, "is there," not "it there." Making the same mistake in all the block comments is just odd.

Kernle 32DLL

(Posted 2009) [#4]

Okay, maybe my description wasnt good enough, so i'll try again.

Experiment 1 & 2 try to show you that the created instances there dont get deleted when GCCollect() is called. But if you call GCCollect() twice, they do get deleted. And in my opinion the instances created are never in any scope. Or am i wrong?

Experiment 3 & 4 (4 is only a different way to show it) try to show the original problem. The instance obiously gets deleted, but with Debugmode turned on, some bytes dont get deleted.

You may say now "heck, 24 Bytes, forget about them". You may be right, but i really want to know what Debug / Non-Debug makes a difference for the GC. Especially why the (in this examples by the way a bit less than 24) Bytes dont get cleaned. It's obius that there is something not right with the GC in Debugmode in my (maybe stupid) opinion.

Nilium: Yes, I forgot about that scope thing...
Oh, and i think i should have mentioned that i'm from germany, and so, my english isnt the best.

N	(Posted 2009) [#5]

SuperStrict

''buildopt:release

Type TestType
	Field Name:String
	
	Function Create(Name:String) 
		Local Instance:TestType = New TestType
		
		Instance.Name = Name
	End Function
	
	Function Create2:TestType(Name:String) 
		Local Instance:TestType = New TestType
		
		Instance.Name = Name
		
		Return Instance
	End Function
	
	Method Remove() 
		DebugLog "[TestType#Remove] Calling GCCollect"
		GCCollect()
	End Method
	
	Method Delete()
		DebugLog "#<TestType:"+Super.ToString()+" @name=~q"+name+"~q> deleted"
	End Method
End Type

Print ""
Print "---------------------" 'clearline for the experiment
Print ""

'-------------------
'Experiment 1
'-------------------

DebugLog "Calling GCCollect"
GCCollect() 
Print "StartMemory: " + GCMemAlloced()

TestType.Create("Hugo") 

'IMPORTANT:
'doing a second GCCollect() here will solve the problem described below
DebugLog "Calling GCCollect"
GCCollect()
Print "ProveMemory: " + GCMemAlloced() 

Rem
	DESCR:
		Creating an instance. Create does NOT return anything,
		so its not possible to ever access any object created
		with this function.
	DEBUG:
		StartMemory and ProveMemory are the same
	NON-DEBUG:
		ProveMemory is bigger than StartMemory, proving
		that our "Hugo" instance has not been killed yet.
		Question: Why? There is no possible way to access
		it anymore, it there?
EndRem

Print ""
Print "---------------------" 'clearline for the experiment
Print ""

'-------------------
'Experiment 2
'-------------------

DebugLog "Calling GCCollect"
GCCollect()
Print "StartMemory: " + GCMemAlloced()

TestType.Create2("Hans")

'IMPORTANT:
'doing a second GCCollect() here will solve the problem described below
DebugLog "Calling GCCollect"
GCCollect()
Print "ProveMemory: " + GCMemAlloced() 

Rem
	DESCR:
		Creating an instance. Create2 DOES return the instance.
	DEBUG & NON-DEBUG:
		ProveMemory is bigger than StartMemory, proving
		that our "Hans" instance has not been killed yet.
		Question: Why? There is no possible way to access
		it >anymore<, it there?
EndRem

Print ""
Print "---------------------" 'clearline for the experiment
Print ""

'-------------------
'Experiment 3
'-------------------

DebugLog "Calling GCCollect"
GCCollect() 
Print "StartMemory: " + GCMemAlloced()

TestType.Create2("Ralf").Remove()

'IMPORTANT:
'note that a second GCCollect() here WONT help
DebugLog "Calling GCCollect"
GCCollect() 
Print "ProveMemory: " + GCMemAlloced() 

Rem
	DESCR:
		Creating an instance, and killing at with the returned instance
	DEBUG:
		ProveMemory is bigger than StartMemory, proving
		that our "Ralf" instance has not been killed yet.
		Question: Why? There is no possible way to access
		it anymore, it there?
	NON-DEBUG:
		StartMemory and ProveMemory are the same
EndRem

Print ""
Print "---------------------" 'clearline for the experiment
Print ""

'-------------------
'Experiment 4
'-------------------

DebugLog "Calling GCCollect"
GCCollect() 
Print "StartMemory: " + GCMemAlloced()

Print TestType.Create2("Herbert").Name

'IMPORTANT:
'note that a second GCCollect() here WONT help
DebugLog "Calling GCCollect"
GCCollect() 
Print "ProveMemory: " + GCMemAlloced() 

Rem
	DESCR:
		Creating an instance, and print'ing by its returned instance
	DEBUG & NON-DEBUG:
		StartMemory and ProveMemory are the same

	WARNING:
		If you delete the whole Experiment 3 out of this sourcefile,
		Experiment 4 will react the same way like Experiment 3.
EndRem

Print ""
Print "---------------------" 'clearline for the experiment
Print ""

I think you'll find that the instances do get deleted.

Kernle 32DLL

(Posted 2009) [#6]

Ok thanks for this improvement. Now compare Experiment 3 with Debugger On and Off.

DebugOff

Calling GCCollect
StartMemory: 16526
[TestType#Remove] Calling GCCollect
Calling GCCollect
ProveMemory: 16538

DebugOn

Calling GCCollect
StartMemory: 15710
[TestType#Remove] Calling GCCollect
Calling GCCollect
#<TestType:017D47E0 @name="Ralf"> deleted
ProveMemory: 15710

Just as i tought, with Debugmode Off, the instance gets not deleted (explaining the left-over bytes). The question now is: Why? Thats the point i was aiming at with this thread in the first place.

Also, if you delete Experiment 3 as suggested in the code, you'll see the same effect on that Experiment 4, too. Because with Experiment 3 in there, Experiment 4 deletes correctly with Debug On and Off. Meaning: This problem only occoures once, after that, the GC does work normally again.

N	(Posted 2009) [#7]

The GC is working normally already. The GC doesn't always free memory because the memory might be reused later. If you don't believe me, go look at its source code.

TaskMaster

(Posted 2009) [#8]

Also, you are not guaranteed that a delete will be called when your program ends.

Kernle 32DLL

(Posted 2009) [#9]

I still dont get it. Why does the GC NOT delete TestType:017D47E0 @name="Ralf" with DebugMode On, while he does with DebugMode Off? There is no reason whatsoever, or am I overlooking something? And no, I havent see into the GCs code yet, and I dont quite thing it would help me.

xlsior

(Posted 2009) [#10]

you're pretty much telling the garbage collector to feel free to get rid of something now, that it's OK to clear it.
There are no guarantees that it actually does it right there and then, since it tends to save up some work and then does it all at once.