From: Christian Neukirchen Date: 2005-11-26T03:18:29+09:00 Subject: Re: `finalize' method? Jim Weirich writes: > chneukirchen wrote: >> What's the problem if this method ran on the first GC once and then >> the object just stayed around? I.e. have a three-pass GC, mark, run, >> sweep? > > There are two problems: > > (1) Detecting that the finalizer has created new reference to a object > scheduled for collection is problematic. I'm thinking this would > require a new mark pass to detect. No, this is not required by my scheme. Methods which have a finalize will require two sweeps to actually get removed (that's not that bad, the second one will follow soon if the first one wasn't sucessful). You need to keep track of the objects whose finalizer has been run, yeah. I'm sure we can use a bit left over somewhere for that... > (2) What is the state of an object that has been finalized, but sticks > around afterwards? Is it valid to call methods on it? After all, > supposedly all of its resources have been finalized at this point. And > when it becomes eligible for collection again, does the finalizer need > to run again or not? It is unreclaimed. Yes. Yes. No. Yes. You can keep track of disposal using an instance variable. > Most languages that allow finalizers explicitly state that creating new > references duing finalization is not allowed and depend upon the > programmer to follow that rule. Ruby handles it by making it impossible > for the programmer to break that rule (i.e. the finalizer doesn't get a > reference to the object, making it difficult to create a reference to > it). That is a valid option, but I think Ruby can do better at little cost. > -- Jim Weirich -- Christian Neukirchen http://chneukirchen.org