From: Sean Middleditch Date: 2002-02-24T05:36:37+09:00 Subject: Re: Object/Memory Management On Sat, 2002-02-23 at 15:13, Sean O'Dell wrote: > > On Sat, 2002-02-23 at 14:01, Sean O'Dell wrote: > > > Isn't there a way we can *explicitly* destroy objects? I like to keep > > > things tight and clean in my code, and simply walking away from objects > I've > > > created absolutely freaks me out. I don't like leaving my program > bloated > > > up in memory with objects that I really only meant to exist for just a > split > > > second while it did something. > > > > You can call the GC routines to do cleanup at any time you want. > > Yes, but I'm under the assumption that calling for GC cleanup causes the > entire list of living objects to be checked. That's not very efficient...I > like objects to go away when I know I'm done with them. The only other option I can think of is to add reference counting. Referencing objects, plus the GC, will set the reference count. However, every time the GC is run, it would have to do a preliminary run of the whole object list resetting the reference count (which would be a big performance hit). But then, at least, you'd always be able to be sure an object is not referenced by anything (0 references? delete!) Of course, an object may have "ghost" references, causing you to think you can't delete the object. Of course, the GC would still work, and delete the objects anyhow. I believe this is how Python (used?) to do it. It more or less wasn't as efficient as Ruby with regards to memory or CPU usage (two memory systems to eat CPU time, plus each object would have to have a reference count field - not to mention that, theoretically, the reference count could roll over, causing bugs). > > > The reason explicit object destruction can't work is because the > > interpreter has no idea what objects reference the object you are > > destroying. You could very easily cause dangling pointers, and then a > > crash not too long afterwards. The best thing to do is, after you are > > sure you want the object destroyed, call the GC routines. That will > > clean up the object, but *only* if it isn't referenced by anything. > > I guess I don't understand how GC works. I assumed that it walks the entire > list of living objects and gets rid of the ones no longer in use. It seems > that it would be easier to just check one object rather than every object in > the list. Well, it is very efficient to do it the way Ruby does it. Assuming you just let the object live until Ruby decides to kill it. I still don't see why you want to delete these objects right away - what platform are you working on? I can see this in embedded apps or consoles, but not many other places. > > If the interpreter has no idea what objects reference what, how does garbage > collection work? How does the garbage collector determine when it's ok to > get rid of an object? Well, it works like this. Ruby has a list of all objects in existance. When the GC is run, it starts with the base objects (any global variables/functions/classes/etc.). For each of those objects, it marks the object as "in use". Then, for each object in use that it finds, it looks at the object is references. Those objects are marked in use. It does this until it has scanned every in use object. Then, the sweeper comes in and destroys any objects that aren't "in use" (not referenced by any object in use). Of course, the GC doesn't work exactly like that, but it's the general idea (The Ruby website, last I checked, had some links to very technical discussions on the various types of GC and how they work - Ruby uses a variation of the Mark and Sweep GC). > > Sean >