Deleting the 'Garbage Way'

ID:273471
 
May 28 2010, 5:37 am
I've heard Lummox JR say something about putting a datum's loc to null to delete it.Something about a Garbage Eating Monster coming and eating it.(If I am not mistaken).

Now applying this practically.
mob.loc= null // this mob is in danger of being the garbage eaters food! (if I am not mistaken;)

Now applying this visually!
obj/the_obj
//History of teh object
/*
This obj was splashed to a client screen with a specified screen_loc!
*/
//now lets do something like (note-I am not precise)
proc/become_food()
 client.screen-=the_obj // removing from the screen
 the_obj.screen_loc=null // setting the screen_loc to null (i think it gives a warning!)
 the_obj.loc=null // is this obj gonna be a target of the garbage collection?

So I am waiting for a long theory about the garbage thingy. =P
and I need the answers to the situations above, so no links. !=P!
May 28 2010, 6:08 am
Iain Peregrine talks about this a little bit here.

Taken straight from the reference:

garbage collection
At runtime, data objects are garbage collected. That means data which is no longer in use gets automatically deleted to free up system memory. This applies to text strings, lists, savefiles, datum objects, and so on.

The garbage collector works by using an efficient reference counting system. Once an item is no longer referenced by any variable, it gets deleted. For the most part, that frees you from having to think about memory allocation, which is wonderful, especially in the case of text strings, which tend to be allocated on the fly all over the place.

There are a couple provisos that you should note. One is that circular references will never be deleted by the garbage collector. By circular reference, I mean a pair of objects with variables that point to each other, or even an object with a variable that points to itself. In rare cases, you may even depend on this behavior. When you are done with such objects, you should either null out the circular reference, or you should forcibly destroy each object with the del instruction.

An object with running or sleeping procs is referenced by the src variable of those procs and will therefore not be thrown out.

Another note is that the world.contents list does not count as a reference. Otherwise, /mob and /obj objects would never be deleted, which is not the case. Note that objects which are contained by another object or which contain objects themselves are referenced and will not be deleted. That means an object must be at loc=null with no contents and, of course, no other references anywhere in order to get deleted by the garbage collector.

Mobs with a non-empty key and all objects with non-empty tags are also immortal.

Turfs and areas do not currently get garbage collected.

When the world shuts down, all objects are destroyed, whether they are referenced or not. You don't have to worry about system memory getting consumed by persistent objects. That doesn't happen.

In general, people who do not like reference counting garbage collection should be happy that DM provides a del instruction, allowing you to take charge and delete things whether they are referenced or not. Another nicety is that this automatically nulls out any existing references to the object, so you don't end up with dangling references to a deleted object, which can otherwise be a great source of instability and mysterious bugs.
May 28 2010, 6:33 am
Setting an object's loc to null does not automatically delete it. Read the Dream Tutor article Green Programming, particularly the "Purging Cleanly" section, for more specifics on how the garbage collector works.

Basically, it won't be deleted until there are zero variables pointing to the object (at which point, it would generally be useless anyway), and the object has no procs which are running. The reason why loc must be null is because if A.loc = B, then B.contents contains A, and therefore there is a variable pointing to A.
May 28 2010, 7:27 am
The garbage collector works by looking for items that are no longer in use, and deleting them automatically. The way it determines "in use" is that every object has a reference count, which is basically another way of saying how many other things are expecting it to stick around. Almost everything in the language is reference-counted, except for turfs, cache files, and a few other types. Even most internal object types are reference-counted.

So, here's a short list of what kinds of things contribute to the reference count of an object:

- Any var holding that object
- A user-defined list with the object as one of its items or associated items
- client.screen, client.images, and certain other special lists
- A container (e.g., whatever has the object in its contents list)
- Any running, sleeping, or spawned proc with the object as src or usr
- A datum with a tag is not deleted automatically
- A mob with the key var set is not deleted automatically

When you use del() manually, the garbage collector has to scan to find all the other references and replace them with null. This is more time consuming.

Note that in the above list, loc does not count as a reference. If mob M is holding object O, O is referenced by M.contents but O doesn't necessarily have any references to M. The loc var doesn't need to add to the reference count, which is good because it means if you move the container to a null location and nothing else is using it anymore, all its contents can probably be deleted too.

One thing to keep in mind about reference counting is that it's just a count; it gives the server no idea of whether a reference is really meaningful or not. It is possible to have a circular reference, which is a case where object A has a var pointing to object B, and object B has a var pointing to object A. Even if nothing else is making use of A or B, they're using each other so the server will think they must be important. They should both be deleted, but they aren't because there's no way for the garbage collector to tell they've been kicked out of the party.

Turfs are not reference-counted because they are only ever created or destroyed by changing the world.maxx/y/z vars, or by the initial map load when starting the world. Reference-counting turfs would therefore be pretty silly.

Contrary to another post, areas are reference-counted. If you have an area that is no longer in use, it can be deleted. I'm not positive if being on the original map spares the area from elimination, however; what I can tell you is that areas created at runtime are definitely fair game.

Typically you'll only run across garbage collection issues for objs, mobs, lists, images, savefiles, and datums. Areas are a minor concern here but they do have a place in that list. Anything else, except clients, you're pretty much never going to use del() on directly. (What about /icon and /sound? Those are datums too, so they're already included.)

For objs, typically all you have to worry about for deletion is whether a var is keeping track of them, and whether they're on the map or in something's contents. For most objs, setting loc=null is a quick way to delete them. If any of the conditions like running procs, tags, etc. apply to them that's a whole other story, but you're usually going to be well aware of those special cases.

Mobs take a little more subtlety because in addition to the obj issues, they can also have a key, and a mob with a key will not be deleted even if it's not in use by a client. All other things being equal, you can delete a mob by settting key=null before setting loc=null.

Datums are easier than objs and mobs, because they have no loc, but trickier in another way. With a datum, you're certain to be have a var somewhere holding onto it. It is much easier, when using advanced data structures, to accidentally create circular references.

In advanced game, lists are going to get created and deleted a lot, so how you handle those matters more than almost any of the above. It's unusual to share a list between multiple objects; usually only one var at a time ever holds a reference to a list, so in that sense they're easy to handle. The key is, with a list more than anything else you want to be absolutely sure you always use var=null to drop the reference rather than del(list) to drop the list itself, which will ensure the garbage collector is given the much easier task of deleting a list with no references vs. trying to look for references it should eliminate.

Hopefully that clears up some questions.

Lummox JR
May 28 2010, 7:41 am
In response to Lummox JR
Interesting, I wish I had known about that when I hosted my Megaman game with all of those hundreds of objects getting deleted by the del() proc all of the time. How much of a significant difference would it make if I had used loc=null instead of del()?
May 28 2010, 8:02 am
In response to Fugsnarf
Fugsnarf wrote:
Interesting, I wish I had known about that when I hosted my Megaman game with all of those hundreds of objects getting deleted by the del() proc all of the time. How much of a significant difference would it make if I had used loc=null instead of del()?

Depending on the size of the game, potentially quite a bit. If the game only has a few hundred objs, mobs, turfs with vars set, etc., then the scan isn't nearly as bad, but doing it hundreds of times per tick still is going to chew some clock cycles.

Lummox JR
May 28 2010, 8:06 am
In response to Lummox JR
After reading up more on this, I feel greatly enlightened and feel I have the potential to be a far far better programmer with this knowledge. This is the first time I had ever even heard the term "Garbage Collector" on BYOND, so I had never actually learned about it. I really think this should be a topic that is stressed more around here. Sure, it's in the reference, but hardly talked about at all outside of it. With DM being my first programming language, I learned with the del() proc, so I had never really heard of this concept before until this very topic actually.
May 28 2010, 8:08 am
In response to Fugsnarf
Fugsnarf wrote:
Interesting, I wish I had known about that when I hosted my Megaman game with all of those hundreds of objects getting deleted by the del() proc all of the time. How much of a significant difference would it make if I had used loc=null instead of del()?

I dunno, but here's a funny guess!
//this is what the del instruction does 
datum.del()
 for(V in vars)// this loop consumes time and cpu
  vars[V]=null
// now call the garbage monster using some BYOND dev trick
//Monster checks the datum
//Monster Eats the datum
//tha da the datum is as good as null


That was a joke! I have no idea on how the Devs do it!Its 'Behind The Scene Trick'

Thanks Guys, esp Lummox JR (for writing that long!;D)

Again Thanx Lummox JR for lighting a firewood(that was wet) in my brain!

EDIT: My Answer was too late. =P