From: jweirich@... Date: 2001-08-13T12:34:09+09:00 Subject: [ruby-talk:19623] Re: Forced garbage collection >>>>> "Florian" == Florian G Pflug writes: Florian> Well.. but on the other hand, why isn't the block Florian> collected, and then the object? Because the block is Florian> needed, when the object is destructed. This seems to be a Florian> kind of "circular dependency" - or in other words a Florian> deadlock. The block is referenced by the ObjectSpace data structures (whatever they are) that tracks finalizers. This prevents the block from being GC'ed. The block references the object, so the object can't be GC'ed either. The object has no reference back to the block (AFAIK), so there are no cycles in the object graph. -- an aside -- When I read about Ruby's finalizer, my first impression was "How Odd". Why were we defining the finalizer outside the object. Then I realized that this particular scheme avoids an oddity that exists in Java finalizers. In Java, the finalizer is call just *before* the object is collected. This means the finalizer can do something weird, like store a reference to the object in a global variable. This means the object can not be GC'ed. In ruby, the finalizer runs *after* the object is GC'ed. There is no more object, so the funky "save the object reference in a global" problem can't happen. So, how do we get to the data formally stored in that object? Well, that's what the block closure is for. We make sure we create the closure in such a way that it "remembers" anything we need to dispose of at finalization time. This also means that we had better be careful not to accidently create a reference to the object. 1) It won't be there when finalization is done, and 2) the reference keeps the object from being collected. -- -- Jim Weirich jweirich@one.net http://w3.one.net/~jweirich --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)