From: Justin Johnson <justinj@...>
Date: 2002-09-04T11:23:36+09:00
Subject: Re: Best GC for Ruby?


> Out of curiosity, have you given this a shot to see how performance
> looks? I've been debating the merits of generational collection, but
> I've been worried about the performance impact (and the code hassle)
> of maintaining generation barriers.

I think I need to allocate a bit of time for experimenting to see just what
the impact is.  I don't much like the idea of maintaining software write
barriers and hardware write barriers are no go for me.

Interestingly, in my implementation I've got a class called RbValue which
represents Rubys internal VALUE.  There's more to it though.  It can take
the behaviour of an integer or a pointer to an object.  The '=' operator is
overloaded and there is significant debug only safety code.  An RbValue
object can cast to an RbObject* if it's setup as an RbObject*.

Example:

RbValue Value1 = 10;                        // Value is an integer (FIXNUM)
10
RbValue PtrObject = pObjectA;        // Value is an object ptr.

Because the '=' operator is overloaded (with an inline so it retains speed
in release builds) I have an ideal point at which to intercept the setting
of RbValues that are pointers to objects.  It would also be possible (and
desirable?) to create a destructor for RbValues that deregisters them from
remembered sets.  I'll have to think about that.

For C code I don't think you can get away from having to use macros.

The other major problem with software write barrier is that I believe that
fastest way is to use card marking with 1 byte (as Matz mentioned).  This
means that you need to be able to find all data pointers within a card, or
chunk of heap.  For my current system, data pointers are identified by the
programmer manually so this idea doesn't seem compatible.

--
Justin Johnson