From: Michael Schneider <michaels@...>
Date: 2002-09-02T01:18:43+09:00
Subject: Re: Why Ruby Uses Mark-and-Sweep GC?

I am working in a major CAD system, and we manage our own memory (Once 
you get past
a couple of gig in memory, the vendors memory mgmt break down).

I would like to use ruby for a scripting lanague in this application, 
but I want to limit Ruby's gc
to Ruby objects,  I have a requirement for our C++ objects to use there 
own (non-ruby gc'd)  memory.
 
We overload new for all of our objects, and have a STL allocator that is 
tied into our memory system.

I think that an argument can be made for Ruby to use memory that is not 
managed by
the Ruby GC.

I am open to other suggestions, any ideas on this one??

Thanks,
Mike


Yukihiro Matsumoto wrote:

>Hi,
>
>In message "Re: Why Ruby Uses Mark-and-Sweep GC?"
>    on 02/08/29, William Djaja Tjokroaminata <billtj@z.glue.umd.edu> writes:
>
>|Do you think it will be beneficial to add C API for Ruby objects that will
>|not participate in the mark-and-sweep gc in a future release of Ruby?  I
>|think in this way we expand Ruby usefullness to include real-time
>|programming.
>
>I don't think so.  What if non GCed objects refer GCed objects?
>We have to maintain some kind of "remembered set" (the list of GCed
>objects referred from non GCed objects).  Or we will have dangling
>references.  I believe such effort should be done by machines.  In the
>GC field, this is called "generational garbage collection", which
>scans long-lived objects less often.
>
>I have a plan to use generational GC in Ruby in the future.
>
>|Also, garbage collection is not an essential element of Ruby, is it?  If
>|some part of Ruby is not garbage-collected, Ruby is still Ruby, isn't
>|it?  I think this will even add to Ruby's luster.
>
>If we have to maintain "rememebered set" by hand, it will not be Ruby,
>I think.
>
>							matz.
>