NewsForumsCodeLogsGallerySpecsSearch

Delete Keyword

BlitzMax Forums/BlitzMax Programming/Delete Keyword

beanage(Posted 2009) [#1]
Hey,

I got a (maybe its actually two) short questions;

I assume the [Delete()] Method of a type will be called by the GC, when an object is supposed to be deleted, wont it?

So, what if I do the following:
Type myType
   Global MyGarbageCollection:TList = CreateList()
   Method Delete()
      MyGarbageCollection.AddLast( Self )
   End Method
End Type
, namely create a new reference when the refcount reaches zero.. I think my intention is self-explanatory, isnt it?

Thank you,


beanage(Posted 2009) [#2]
So I just typed my example code into the ide and it all works as i want it to work.. I love BlitzMax. Amen.


Czar Flavius(Posted 2009) [#3]
You can temporarily suspend the garbage collector, if you need to.

Is the Delete method safe to use? If it is, I might start using it.. (I'm worried it's not completely safe, because the garbage collector deletes objects when it wants to, not the instant an object loses its references)


Htbaa(Posted 2009) [#4]
I wonder if this is a safe thing to do. As soon as the GC deletes your object you store it inside a TList. I wonder how long the pointer to it stays valid...

Also, if it doesn't delete the object it means that you never can delete the object... I don't see why you would want to do that.


beanage(Posted 2009) [#5]
What is more performant: Holding a new reference to an existing unused object, and reuse that one if a new one is needed, or permanently re-allocating memory for new objects? I dont know, but I'm excited to see the results of this :)


Scienthsine(Posted 2009) [#6]
Reusing objects can be good, but I wouldn't advocate doing it this way. In whatever place you remove your object from all of it's references, put it in your deleted list there before it is removed. This would be a much cleaner way of doing it. If you have several places that could reference the object, and aren't sure which one will be the last, then this would make it more difficult... but I would still look for a better way.

But... aslong as the pointer remains valid (check this... see if the same object gets it's delete called more than once), and you realize that this prevents your objects from getting collected, then you should be gone.

Do be sure to figure out if the garbage collector counts references made in the delete call, otherwise that memory could get collected in the middle of being used. -And- that the delete call gets called more than once for the same object loosing reference again. (Otherwise you'll get nasty memory leaks.)


Brucey(Posted 2009) [#7]
I wonder if this is a safe thing to do.

I can't imagine that it would be...

Considering that it calls bbGCDeallocObject() after calling Delete(), when using the default GC.


Czar Flavius(Posted 2009) [#8]
Is there a safe way of having an object deconstructor?


Brucey(Posted 2009) [#9]
I use Delete() all the time, but obviously not to "work behind the garbage-collector's back".


Czar Flavius(Posted 2009) [#10]
I mean, say I have a missile, and when it hits all references are removed.. can I put the code to cause an explosion in delete?


Brucey(Posted 2009) [#11]
No, because you won't know when the object itself is going to be GC'd - that's entirely up to the garbage collector.


Czar Flavius(Posted 2009) [#12]
Even if I pay taxes the garbage collector won't do as I say?? :P


Brucey(Posted 2009) [#13]
Eventually ;-)

You can manually call the collection, but it might not be very efficient to call this all the time - and it collects everything, which may not be what you want.

Better to perhaps move your missile from a "live" list to a "dead" list, where it can run its explosion routine, then when finished that, remove from the "dead" list.


N(Posted 2009) [#14]
You really don't want to try to retain an object when it's being finalized. Lots of things can go wrong there... the object you access might have been freed already and then you're referencing memory that might still be allocated but not associated with what you think it is. Lots of room for error.


beanage(Posted 2009) [#15]
Oh, i didnt expect this thread to cause that big waves, its just an experiment. I love experiments :) I *think* if its a good gc, it should recount refs after delete(). Mmmh .. I will need to test it.


beanage(Posted 2009) [#16]
Global MyCollection:TList = CreateList()

Type MyType

	Field x
	Method Delete()
		mycollection.addlast(Self)
	End Method
	
End Type

Graphics 800,600

While Not KeyHit( KEY_ESCAPE )
	
	Local o:myType = New MyType
	o.x = mycollection.count()

Wend

For Local a:myTYpe = EachIn MyCollection

	Print a.x

Next


Watch those results. I hate pessimism, but I'm afraid those dont allow any optimism anymore, pity.


Brucey(Posted 2009) [#17]
I *think* if its a good gc, it should recount refs after delete()

But that doesn't make sense now, does it?

It's calling Delete() because it has decided there are no refs, and is about to free memory.

Now you are saying, "well, hold on. I actually want to re-reference this object now, even though collection has begun".

Not a very good idea.

It's like that stale sandwich you threw into the trash yesterday. But you've decided to rescue it before the trash-men come to collect the garbage, scrape off the mold, and have it for lunch :-p


beanage(Posted 2009) [#18]
Thats one funny picture brucey ;) My intention was catching the sandwich someone else was about to throw :) recycling :D

Looks like we posted at the same time. I tested it, an it looks like it frees the mem of the object after calling delete, without caring about my refs /: Looks like my first exaple posted was an optimistically short one.

I tend to do this. sry.


Brucey(Posted 2009) [#19]
I tested it, an it looks like it frees the mem of the object after calling delete, without caring about my refs /:


Right. Because there needs to be a point in time where it *can* garbage collect the object. And calling Delete() tells YOU, that the object is about to be deleted. No turning back. No passing through Go! :-)


Scienthsine(Posted 2009) [#20]
And I'd like it to stay that way. Trying to keep up with references made during deletes and such would be wasted processor cycles for everyone who uses bmax for a very small benefit .

Is nice to know how it stands at the moment though, for reference. :)


beanage(Posted 2009) [#21]
I'd like it to stay that way

So maybe you wont like BlitzMax 1.36.

Trying to keep up with references made during deletes and such would be wasted processor cycles

The recent BlitzMax Update does. I wonder whether Mark read this Thread. If the update would just have come 2 months earlier, or just someone had told that it was about to be implemented, I would have been spared of writing a 500 lines of workaround. Now that it is supported, this kinda sucks.

edit: Is there any place where you can read what is to be implemented next? I'm just a little pissed right now :(