Re: Why Ruby Uses Mark-and-Sweep GC?

Hi Matz,

Thanks for the suggestion.  However, I think NArray is different, because
it is a collection of "objects" that can be represented as native data
types in C (such as int and double).  When the objects are really Ruby
objects, I still cannot see an easy way to handle them as a collection.

In my case, the user creates certain Ruby objects with explicit commands
and these objects exist until the end of the process, unless the user
destroys them with explicit commands.  I store these objects in a global
rb_ary (and therefore automatically marked).  Therefore, because I
know when these objects are created and destroyed explicitly, I want them
not to participate in the mark and sweep GC.  I think I just need valid
Ruby objects (valid VALUE's) that the user can interact with, but the
creation and deletion of these VALUE's are not under the control of Ruby
GC.  Will creating a second "RVALUE **heaps" such as that in gc.c be a
good idea?  (Isn't that fundamentally the object model is orthogonal to
how the object memory is managed?)

If we indeed can create VALUE's which are not under the control of Ruby
GC, then I think we really can use Ruby in real-time programming (subject
to certain restrictions on the user's Ruby script, of course), as the
number of objects that need to be marked can be made much smaller (and
therefore the marking phase will not take as much time) and be made
relatively independent of the actual number of "Ruby objects" in the
system (not order N anymore).

Regards,

Bill
============================================================================
Yukihiro Matsumoto <[e-mail]> wrote:
> I think what you want is contradicting with mark&sweep GC, which Ruby
> uses you know.  If you want to have objects out of GC sweep, you have
> to define something handle "these objects" as a collection.  See
> NArray for example.

> 							matz.