From: Dan Sugalski Date: 2002-08-24T09:45:43+09:00 Subject: [OT] Re: Why Ruby Uses Mark-and-Sweep GC? At 9:40 AM +0900 8/24/02, Mauricio Fern�ndez wrote: >On Sat, Aug 24, 2002 at 03:27:58AM +0900, Dan Sugalski wrote: >> At 3:18 AM +0900 8/24/02, Perry E. Metzger wrote: >> >Dan Sugalski writes: >> >> At 1:18 AM +0900 8/24/02, William Djaja Tjokroaminata wrote: >> >> >I think one of the problems with reference counting is the circular >> >> >reference, which cannot be handled by the gc. >> >> >> >> That's one problem. Reference counting is also more expensive over >> >> the long run than more automatic methods. Also more error-prone. >> > >> >There are, of course, better gc's than mark and sweep -- compacting >> >collectors and generational compacting collectors come to >> >mind. Writing an implementation that deals with a compacting collector >> >can be a royal pain though -- you never know when an object will get >> >moved out from under you. >> >> Believe me, I'm well aware of that pain. :( >> >> When dealing with external libraries, a pure copying collector's not >> an option--Oracle, for example, would *really* hate it if you screwed >> around in its internals changing references to things. >> >> The practical alternative is to have moveable and nonmoveable parts >> of objects, and a mechanism to pin objects so they temporarily don't >> move. It's what we've done with Parrot. Not the only solution, but an > > adequate one under the circumstances. > >Is Parrot's convoluted copying GC generational? The GC's not particularly convoluted. At the moment, though, it's not generational. That may change in the future. -- Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunk