From: Dan Hable <DHable@...>
Date: 2001-11-29T07:32:50+09:00
Subject: [ruby-talk:26845] Re: Ref Counting (was KDE or GNOME curiosity	question...)

I wouldn't implement any finalizer like Java. IMO the finalize method is the last (final) method that will be called before the GC reclaims the object. This method should do the minimum to get the object back into a sane state for destruction.

I also wouldn't allow the finalizer to reclaim a reference back to itself, like Java. Then you avoid the whole issue of the finalizer being called on one time through the process but not the second. Maybe I don't see the useful logic, but your program should do unexpected things if you just start droping references to objects that you still need.

>>> mchahn@facelink.com 11/28/01 03:59PM >>>
Thanks, that was very clear.

Java also had a "half-dead" state that the finalizer could wake back up
from.  If I remember right there were four total states.

----- Original Message -----
From: "MikkelFJ" <mikkelj-anti-spam@post1.dknet.dk>
Newsgroups: comp.lang.ruby
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>; <undisclosed-recipients:>
Sent: Wednesday, November 28, 2001 1:53 PM
Subject: [ruby-talk:26841] Re: Ref Counting (was KDE or GNOME curiosity
question...)


>
> "mark hahn" <mchahn@facelink.com> wrote in message
> news:004801c17850$95ec4250$2a8bb8d0@web4...
>
> > For example, only references to a File object that rely on the object
> being
> > opened or closed need to be considered when deciding whether the file
can
> be
> > closed at any particular point in time.
>
> Most of these issues can be handled directly by subscribe / unscribe
> semantics of an object. You may keep a link to a subscriber for events,
but
> you can also choose to only maintain a refcount. In any case you perform
> cleanup when the number of subscriptions hits zero. The object may then be
> finalized at a later point - or reused in an object pool.
> This requires no changes, but a general subscriptions Mixin could be
> written - one for refcount and one with event notifications. Very trivial.
>
> related:
> Microfts GC for .NET has some internal confimation logic in the GC. An
> object is finalized before memory is reclaimed. During this process the
> object is parked in a pseudo state where it is neither allocated nor
> dealloced. The object can in the finalization choose to be revived and it
> can modify the heap by allocating objects requring rescans. I don't recall
> the details - its a bit complicated but not that complicated. There is an
> article at MS developer journal on the issue.
> However, their solution does not handle the problem of early finalization.
> You either need compiler scope control or som manual unscribe method.
> You could combine finalize with unsubcribe such that a user object will
> automatically calls unsubscribe on a resource if its owner failed to do
so.
>
> part 1
> http://msdn.microsoft.com/msdnmag/issues/1100/GCI/GCI.asp 
> part 2
> http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/GCI2.asp 
>
> MikkelFJ
>
>
>