From: William Djaja Tjokroaminata Date: 2002-08-29T22:32:37+09:00 Subject: Re: Why Ruby Uses Mark-and-Sweep GC? Hi Matz, Thanks for your consideration. I think generational GC will be good enough, if it scans long-lived objects less often. I will assume that it will have a parameter to control how "often" is less often, and we can just tweak this for specific applications. Regarding maintaining "remembered set" by hand, no, no, it will never be done from the Ruby side itself. And therefore the "Ruby language" itself stays exactly the same. Only from the C side there will be some difference. I think when I asked you whether there is an official set of Ruby C API's some time ago, you answered "yes and no". Therefore, if the Ruby side stays the same but the C side changes (in terms of memory management), I think you really have all the privileges to decide whether it is still Ruby or not. I am looking forward to the generational GC in Ruby. Many many thanks, especially for the wonderful language that you created. Regards, Bill ============================================================================ Yukihiro Matsumoto wrote: > Hi, > In message "Re: Why Ruby Uses Mark-and-Sweep GC?" > on 02/08/29, William Djaja Tjokroaminata 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.