From: Justin Johnson <justinj@...>
Date: 2002-08-29T19:32:30+09:00
Subject: Re: Why Ruby Uses Mark-and-Sweep GC?


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?

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

--
Justin Johnson

"Yukihiro Matsumoto" <matz@ruby-lang.org> wrote in message
news:1030578701.908799.13257.nullmailer@picachu.netlab.jp...
> Hi,
>
> In message "Re: Why Ruby Uses Mark-and-Sweep GC?"
>     on 02/08/29, William Djaja Tjokroaminata <billtj@z.glue.umd.edu>
writes:
>
> |Do you think it will be beneficial to add C API for Ruby objects that
will
> |not participate in the mark-and-sweep gc in a future release of Ruby?  I
> |think in this way we expand Ruby usefullness to include real-time
> |programming.
>
> I don't think so.  What if non GCed objects refer GCed objects?
> We have to maintain some kind of "remembered set" (the list of GCed
> objects referred from non GCed objects).  Or we will have dangling
> references.  I believe such effort should be done by machines.  In the
> GC field, this is called "generational garbage collection", which
> scans long-lived objects less often.
>
> I have a plan to use generational GC in Ruby in the future.
>
> |Also, garbage collection is not an essential element of Ruby, is it?  If
> |some part of Ruby is not garbage-collected, Ruby is still Ruby, isn't
> |it?  I think this will even add to Ruby's luster.
>
> If we have to maintain "rememebered set" by hand, it will not be Ruby,
> I think.
>
> matz.
>