From: matz@... (Yukihiro Matsumoto)
Date: 2002-08-30T02:57:44+09:00
Subject: Re: Why Ruby Uses Mark-and-Sweep GC?

Hi,

In message "Re: Why Ruby Uses Mark-and-Sweep GC?"
    on 02/08/29, "Justin Johnson" <justinj@mobiusent.com> writes:

|And having a "remembered set" automatically catered for usually relies on
|hardware supported write barrier which could get prohibitivly expensive in
|the case outlined below.
|
|Incidentally, my garbage collector is mark-and-sweep with incremental
|sweeping.  Incremental sweeping was easy to add and distributes the sweeping
|cost amongst allocations.  It was easy to add.  If Ruby doesn't do this
|already, it might be worth adding?

It doesn't do this yet.  I guess it is worth adding in the (near) future.

|I'm looking into making it generational although the sticking point seems to
|be make the generations work without support for hardware write barrier.

Recent researches tell us that hardware supported write barrier is not
good.  It is slow (signal interrupt and context switch to/from kernel
cost much), and not portable (mprotect(2) is not universal).  Software
write barrier is cheaper.  Good implementation requires several
additional machine instructions per write, if GC can work cooperatively
with mutator.  See the "Jones and Linn" book.

							matz.