From: Rick DeNatale Date: 2008-01-10T03:57:44+09:00 Subject: Re: Manual Memory Management On Jan 8, 2008 8:09 PM, Kurt Stephens wrote: > > MenTaLguY wrote: > > However, more mature garbage-collected languages (i.e. smalltalk, lisp dialects, > > java, other JavaScript implementations, etc.) with garbage collection almost > > universally use some variant of mark-and-sweep instead. There are a lot of > > reasons for this, including nice handling of reference cycles (Microsoft's > > JavaScript implementation is notorious for memory leaks) and minimal overhead > > for common reference operations. Generally the amortized cost of mark-and-sweep > > is lower too. > > Copying-compacting collectors perform better in time and space than > mark-sweep collectors in almost all cases, esp. better than conservative > mark-sweep. Allocation in a copying-compacting collector simply > requires incrementing a pointer until the end of the free space is reached. ... > Copying has the nice side-effect of grouping closely referenced > objects together, improving CPU-cache-memory locality. > > But since Ruby internals cater to a very naive foreign-function > interface to C extensions, implementing a copying collector is going to > be difficult and will require major changes to all C extensions. Well, Rubinius seems to use a two-stage GC. Short-lived objects are reaped with a Baker copying collector, after an object survives 16 cycles it gets tenured. Tenured objects are reclaimed using mark-sweep. http://rubini.us/pages/vm. This is a fairly standard variant of today's practice, it seems to be describing what's usually called generation scavenging, which Dave Ungar pioneered in Berkeley Smalltalk and carried over to Self and the hotspot VM. Rubinius also claims to have a compatibility interface with the MRI C-extension API called subtend. I don't know what the restrictions are, if any. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/