I had a good look at the Boehm GC.  The only down side that I could see is
that under Windows, there is no ability to allocate 4k aligned blocks from
the system.  The code allocates larger blocks and sets a pointer inside to
get 4k alignment.  This could be quite wasteful with memory.  On Unix based
systems it's not a problem.

It's good to hear that Rite's GC will be generational.  That should take
care of any performance issues related to Ruby's GC.

For mature generations I'm seriously considering the Train algorithm because
of it's highly incremental and unintrusive nature.  The Mjolner BETA
language has an implementation and achieved good results.

Maintaining the remembered sets without a hardware write barrier is still
posing a problem.  I can't seem to find any good information on software
write barriers.  There didn't seem to be anything in the Jones and Lins
book.

Also, I'm not sure how software write barriers could be introduced without
making extension programming more error prone and difficult.

Maybe I'm missing something?

--
Justin Johnson

"Yukihiro Matsumoto" <matz / ruby-lang.org> wrote in message
news:1030636759.172074.21296.nullmailer / picachu.netlab.jp...
> Hi,
>
> In message "Best GC for Ruby?"
>     on 02/08/29, "Justin Johnson" <justinj / mobiusent.com> writes:
>
> |Matz, did you have any ideas on the GC for Rite?
>
> It will be
>
>   * conservative (to make extension programming easy)
>   * generational (hopefully, to reduce GC perfomance cost)
>
> I'm considering either
>
>   * deferred reference count (1 bit refcount + mark and sweep)
>   * generational mark and sweep
>
> Or I might use Boehm GC for the Rite prototype.
>
> matz.
>