From: Joel VanderWerf <vjoel@...>
Date: 2008-07-30T08:19:09+09:00
Subject: Re: ruby wish-list

Roger Pack wrote:
> Joel VanderWerf wrote:
>> The check for garbage can't be done concurrently with ruby code:
>>
>>    a = []
>>    $a = a
>>    a = nil
>>
>> depending on how the gc process is scheduled, that empty array may
>> falsely appear to be garbage:
>>
>>    # start scan * SNAPSHOT *
>>    a = []
>>    # scan globals
>>    $a = a
>>    a = nil
>>    # scan locals
> 
> Definitely a consideration.
> 
> Do you think this help?  The child process is basically operating off a 
> snapshot of memory, since it was a fork.  It will thus only 'mark as 
> free' the ruby objects that are inaccessible at the time of the 
> snapshot, thus, in this example, not collecting "a" since it...hasn't 
> been created yet.
> 
> The memory is 'reclaimed' by the parent "all at once" so should avoid 
> concurrency weirdness that way, too.  There is always "at most" one fork 
> doing a GC.  Come to think of it, I'm not sure how this would work if 
> you had a process that actually called fork while running, but for 
> single [true] threaded scripts it should work.
> 
> Thoughts?
> 
> -R

Oh, I wasn't understanding your idea, which does seem to make sense now. 
There's the overhead of essentially duplicating the object space of the 
original process in the fork (since mark will write to memory pages). 
Maybe it would be worth this cost (esp. on a second processor) for the 
benefit of not having to stop the main process?

Interesting!

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407