From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Subject: Re: [9fans] Re: advantages of limbo From: David Presotto To: 9fans@cse.psu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 2 Mar 2004 03:02:46 -0500 Topicbox-Message-UUID: 0a75bd42-eacd-11e9-9e20-41e7f4b1d025 On the topic of garbage collectors, one of the main reasons for reference counting objects and immediately releasing them when they become unreachable was to use garbage collection to allow control not only of memory but also resources memory represents. The typical example given is one of windows that go away as soon as the last reference to them (actually the object representing them) goes away. Also, the reference counting had a distinct advantage of being fixed time. We had a terrible time with java systems of the time going away for long periods, both because of the garbage collector going off and because of the odd interactions in finalize routines in various classes. Over the years since limbo appeared, java garbage collection has changed radicly and often, drasticly reducing the 'time to take a coffee break' garbage collection runs. By the 1.4.1 jdk, java included 6 or more gabage collection strategies and all sorts of tuning parameters. Along the way all sorts of user code was written to avoid tickling the collectors at the wrong time or to get things done before they went off. That's a hell of a lot of effort to avoid the small differences advertised by the proponents of m&s and generational gc over reference counting. Of course, limbo isn't immune from odd timings. However, they do require reference loops and those seem not very common amongst limbo programmers.