memory not restored?

BlitzMax Forums/BlitzMax Programming/memory not restored?

Robert Cummings(Posted 2005) [#1]
Strict 
Global img:timage = Null

Print MemAlloced()
img:timage = LoadImage:timage(CurrentDir()+"/graphics/basic1.png")
Print MemAlloced()
img = Null
FlushMem
Print MemAlloced()


Why isn't the same amount of memory restored when the image is freed?


WendellM(Posted 2005) [#2]
Maybe(?) FlushMem itself uses some memory, because adding it before the first MemAlloced gives the same numbers before and after loading/freeing the image:
Strict 
Global img:timage = Null
FlushMem
Print MemAlloced()
img:timage = LoadImage:timage(CurrentDir()+"/graphics/basic1.png")
Print MemAlloced()
img = Null
FlushMem
Print MemAlloced()



tonyg(Posted 2005) [#3]
That's all too confusing. Why not wait the couple of days for 1.12 and check again. We know it has new memory management so maybe it will be fixed/behave differently.


Robert Cummings(Posted 2005) [#4]
Thanks, but this is just a curiosity item, I'm curious about the behaviour (hence not a bug report)


Perturbatio(Posted 2005) [#5]
Bmax doesn't automatically release the memory when you use flushmem, it reserves it in a pool to be used later (because it's faster than requesting memory from the OS), when you create a new type, the pool is used first. This is why using flushmem speeds things up so significantly, it helps prevent you from needing more than is in the pool.


Hotcakes(Posted 2005) [#6]
Yes. It is up to the garbage collector as to when memory is freed. It could be the first call to FlushMem, it could be never.

Oh, and MemAlloced() chews up around 20 bytes I think it is. But that's recoverable by the GC as well...


Yan(Posted 2005) [#7]
Wiki FAQ


Space_guy(Posted 2005) [#8]
I have one of those leaks when i create images wich. it seems not to reuse memory though becourse i can get it to eat and eat and eat and just grow larger. never smaller again. its strange. but i have high hopes on 1.12 so im calm so far.


Dreamora(Posted 2005) [#9]
Did you make sure that the references to the image are given free? (assuming you used OO ie :TImage because if you use int handles you have to mark them to be freed manually with delete)
Never had this kind of error.


Space_guy(Posted 2005) [#10]
yep. timages. and well. there is only one refernece to the image and its overwritten by the new image when it needs to be created. its basicly comes down to the image needing to be of different sizes. anyhow. if the autoflush thing wotn work im probbably going to rewrite it sooner or later anyway.


Robert Cummings(Posted 2005) [#11]
sounds like you're not defining the image as tImage


Space_guy(Posted 2005) [#12]
sounds like it perhaps but timages they are. :)


Robert Cummings(Posted 2005) [#13]
Do you have a small piece of code that demonstrates memory creeping higher all the time? and is flushmem used?


Dreamora(Posted 2005) [#14]
The only case I seen this so far is when images / pixmaps are created about once a frame with high frame rates, in this case the memory will run up to several 100mb due to the overhead you create by not reusing images / pixmap as it should and would be done by all experienced programmers.

Creating millions of new things and drop old at the same time is something like a "way to kill a GC" and should be avoided if possible.


Space_guy(Posted 2005) [#15]
Here is an example. But when looking closer it has all to do with the lockimage. Did i do something wrong here?
Graphics 320,240,0

Local test:timage
Repeat
	test:timage=CreateImage(32,32)
	
	pix=LockImage(test)
	UnlockImage(test)

	FlushMem
	Flip
	Print MemAlloced()
	WaitKey
Until KeyDown(key_escape)



Robert Cummings(Posted 2005) [#16]
Strict

Graphics 320,240,0

Local test:timage
Local pix:tpixmap

Repeat
	test:timage=CreateImage(32,32)
	
	pix=LockImage(test)
	UnlockImage(test)
	
	FlushMem
	
	Flip
	Print MemAlloced()
	WaitKey
Until KeyDown(key_escape)


By defining pix and using strict, the problem goes away. This is possibly because pix isn't defined. I do not know why.

Anyone know why this is?


Perturbatio(Posted 2005) [#17]
Graphics 320,240,0

Local test:timage
Repeat
	test:timage=CreateImage(32,32)
	
	pix:TPixmap=LockImage(test)
	UnlockImage(test)

	FlushMem
	Flip
	Print MemAlloced()
	WaitKey
Until KeyDown(key_escape)




Yan(Posted 2005) [#18]
Anyone know why this is?
pix is an integer handle and needs to be released.

If you must use integer handles...
Graphics 320,240,0

Local test:timage
Repeat
	test:timage=CreateImage(32,32)
	
	pix=LockImage(test)
	UnlockImage(test)
	Release pix

	FlushMem
	Flip
	Print MemAlloced()
	WaitKey
Until KeyDown(key_escape)
...Just don't use em! ;o)


Dreamora(Posted 2005) [#19]
hehe ... thought you did the :Type thing space_guy? ;-)


Space_guy(Posted 2005) [#20]
yaaarr.

Ill check that out. thanks!


Space_guy(Posted 2005) [#21]
Worked great. one less of those pesky memholes fixed then :)