Threaded GC bug?

Archives Forums/BlitzMax Bug Reports/Threaded GC bug?

Tommo(Posted 2009) [#1]
The code:
(You have to use Taskmanager to see the memory usage, GCMemAlloced won't work)


Type tNode
	Field _next:tNode
End Type

Graphics 400, 300

Local currentNode:tNode= New tNode

While Not KeyHit(27)
	
	For Local i = 1 To 1000
		Local newNode:tNode = New tNode
		currentNode._next = newNode  'comment this out to see the difference
		currentNode = newNode
	Next
	                                         
	Flip 0
	Delay(1)
Wend



There is a "currentNode", then I create a new Node to replace it, and make the previous node point to the new one.
Because "currentNode" is the only reachable variable, so the old nodes should get collected.
However, while non-threaded GC works fine, threaded GC seems fail to clear it. The memory usage increases very fast.

But if I don't set old node's "_next" field, GC will work greatly.

I guess maybe it's about "isolation island", but there's no cyclic reference, it's just a single chain.

I found the same problem with TList. Maybe it's a bug?

BMX 133, WinXp.


GfK(Posted 2009) [#2]
I'm not so sure about this new Janet-Street-Porter GC or whatever its called. It seems to have a lot of issues.


N(Posted 2009) [#3]
Mine is sitting at 11.9mb (averaged between runs, each run deviates from that number by about ±.03mb) of memory and not increasing using the threaded GC, but I'm running Mac OS 10.5.7, not XP. Running 1.33 as well.

On another note, if you intend to post code that might attempt to show a bug, 1) use framework, 2) use superstrict, and 3) do not give your types names that already exist (your tnode and brl.map.tnode both exist in your example).

E.g.,
'buildopt:threaded
SuperStrict

Framework Brl.Blitz

Type INode
	Method Delete()
		DebugLog("#<Object@"+ToString()+"> collected")
	End Method
	
	Field _next:INode
End Type

Local currentNode:INode= New INode

' Use ^C to kill the app
While True
	For Local i% = 1 To 1000
		Local newNode:INode = New INode
		currentNode._next = newNode  'comment this out to see the difference
		currentNode = newNode
	Next
	
	Delay(1)
Wend

The above code only has about 2.5mb allocated at the most, and objects are being reported as collected.


BlitzSupport(Posted 2009) [#4]
Yep, same result here when threaded build is enabled (on XP SP3).

I think it's worth Mark taking a look, so I'll move the thread to BlitzMax Bug Reports.

(@Mark: My fault if it's not in fact a bug, but just a quirk in how BDWGC works!)