From: William Djaja Tjokroaminata <billtj@...>
Date: 2002-10-23T05:57:45+09:00
Subject: Re: rb_gc_register_address problem

Your concept is true for C programming in general, but here we are
specifically talking about Ruby gc.  Ruby gc manages a heap of VALUE's
(pointers) that may point to either a valid object or a free object/data
area (not an exact terminology here).

During the mark phase, given a VALUE (not &VALUE) Ruby gc just marks the
object pointed by VALUE.  During the sweep phase, Ruby gc just goes
through the heap linearly, and for any VALUE that does not point to a
marked object, Ruby gc just changes the VALUE to point to a free
object/data area (to be recycled later) and/or "freeing" what the VALUE
pointed to before.

Therefore, we just need to tell Ruby gc a VALUE (a pointer) and not the
address of VALUE (a pointer to pointer).  We gives Ruby a pointer, and
Ruby manages the pointer to pointers.  Therefore, we can as well use a
function such as rb_gc_register_value(VALUE) instead of
rb_gc_register_address(VALUE*) (although the usage will slightly changes, 
but this has nothing to do with feasibility).

Bill
==========================================================================
ahoward <ahoward@fsl.noaa.gov> wrote:
> sounds complicated - why not this simple explanation illustrated here :

(deleted)

> the gc _must_ have a prototype like 'i_can_change_what_memory_you_point_to' so
> it may, for example, point an object to nil.  otherwise it could only change
> the objects pointed to themselves!