ID:162130
 
BYOND will automatically delete a list that isn't be used by anything right? And by anything I mean running procs.
It will be deleted by the garbage collector when it goes out of scope.
In response to Garthor
Out of curiosity, does anyone know how the garbage collector handles circular references? I assume it just leaves them alone - I believe it's a reference-count GC.

Also, as for the OT, lists in procs will be deleted if they go out of scope - like Garthor said:

proc/ListDel()
var/mob/a
for(a)
var/list/b = list()

//List deleted here. Or added to a to-be-deleted internal list. It's gone, anyway.


If a list is a member variable of an object:

mob/var/list/cool_list=list()


it will be deleted when the object is deleted.

Global lists are never deleted (They never go out of scope, see?)
In response to Jp
Jp wrote:
Out of curiosity, does anyone know how the garbage collector handles circular references? I assume it just leaves them alone - I believe it's a reference-count GC.

Circular references are left alone, right. This added to the woes of Deadron during his development of his XML library ([link]); it's natural that he would want to be able to use the scope rules of BYOND's internal garbage collector on XML trees, so that users could merely let the XML object go out of scope.

Hiead
In response to Jp
I think it was in the DM guide where I read the recommendation to get rid of circular references by changing them to null so they can be deallocated.

I'm wondering what proc allows the game to read the amount of memory allocated. I can't find one. It would come in handy when monitoring the game for leaks due to forgetting circular clean-ups.
In response to Traztx
Traztx wrote:
I'm wondering what proc allows the game to read the amount of memory allocated. I can't find one.

Unfortunately, there is no such proc.

Hiead
In response to Jp
Jp wrote:
Out of curiosity, does anyone know how the garbage collector handles circular references? I assume it just leaves them alone - I believe it's a reference-count GC.

Correctamundo. In that case the only way to delete an object is to manually delete it.

For this reason if I think I'm going to have circular references, I keep track of them with a master object. If the master object is deleted, it will delete the objects that it's tracking as well. For example, this is how I'd set up a binary tree in BYOND with up-or-down traversal.

branch
var/value
var/branch
parent; left; right

New(parent, value)
src.parent = parent
src.value = new_value

Insert(new_value)
if(new_value < value)
if(left) left.Insert(new_value)
else left = new(src, new_value)
else if(new_value >= value)
if(right) right.Insert(new_value)
else right = new(src, new_value)

Del()
if(left)
left.parent = null
del(left)
if(right)
right.parent = null
del(right)
if(parent)
if(parent.left == src) parent.left = null
else if(parent.right == src) parent.right = null
..()

tree
var/branch/root

Del()
if(root) del(root)
..()


The tree object is what I'd hold onto for reference counting purposes. If it went out of scope, it'd delete all the nodes in the tree. Otherwise they contain references both up and down so none of the nodes would ever be deleted.

Lummox JR
In response to Jp
Jp wrote:
Out of curiosity, does anyone know how the garbage collector handles circular references? I assume it just leaves them alone - I believe it's a reference-count GC.

Also, as for the OT, lists in procs will be deleted if they go out of scope - like Garthor said:

> proc/ListDel()
> var/mob/a
> for(a)
> var/list/b = list()
>
> //List deleted here. Or added to a to-be-deleted internal list. It's gone, anyway.
>

If a list is a member variable of an object:

> mob/var/list/cool_list=list()
>

it will be deleted when the object is deleted.

Global lists are never deleted (They never go out of scope, see?)


And of course, when a proc ends, any lists it created and are not referenced by objects are also deleted right?
In response to Obs
Any object that is created inside a proc will be deleted, and I'm sure all variables are nulled out.