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

> See "7.5 Inter-generational pointers".  In p.172, "Using bytes rather
> than bits speeds up the write-barrier, reducing it to just three SPARC
> instructions in addition to the actual store".  So it's not
> impossible, at least in theory.

Yes, I've read that very chapter.  If setting a pointer only results in a
byte being set then maybe that's not too bad.  I'm not sure yet.

Let me elaborate by showing some code to show how my Ruby gc works:

C++ .h

class RbNewObject : public RbObject
{
public:
    RUBY_CLASS( RbNewObject, RbObject )

    // Garbage collection traversal
    virtual void gc();

private:
    // Data members...
    RbObject*    pObjectA_;
    RbObject*    pObjectB_;
};

Then in C++ .cpp

void RbNewObject::gc()
{
    gcTraverse( pObjectA_ );
    gcTraverse( pObjectB_ );
}

The garbage collector uses the C/C++ stack to find roots.  Roots can also be
manually registered.  Any object that is to be controlled by garbage
collection must be derived from RbObject (which is in turn derived from an
object called GcObject in my GC library).  When GC objects are being marked,
the objects gc() method is called to trace other objects to mark.
gcTraverse() calls into the garbage collector to do bit marking.  It does
not recurse but uses an iteration technique similar to Cheney's copying.
Using the gc() method means that the garbage collector knows more about the
objects it can collect and therefore cuts down on the number of
misidentifications that the Boehm GC experiences.  It should also make
marking faster.  This is a little more work for the programmer but I think
it's worth the small effort.

So far it's easy for the application programmer to use.  They can change the
pointers simply by setting them to different values.  The GC identifies
valid object ptr's from the C/C++ stack and traverses objects accordingly.

To implement a software barrier, a simple pointer set like:

pObjectA_ = pOtherObject;

would have to become:

setPointer( pObjectA_, pOtherObject );

or, at least for C++, possibly a template smart ptr style method could be
used.  The definition would be something like:

wbPtr<RbObject>    pObjectA_;

and then setting becomes the usual:

pObjectA_ = pOtherObject;

Either way, I'm a little concerned about the overhead this is going to place
on all pointer setting.  I think I'd have to implement it and take a look at
the generated assembler.

> It can be, if all attribute modifies are done by API.  Though we can't
> assume this if we are developing general purpose collector like
> Boehm's.

Did you mean like in the setPointer macro/function above?

--
Justin Johnson