On Apr 8, 2005, at 1:39 PM, Charles Mills wrote:

> Lothar Scholz wrote:
>> Hello Charles,
>>
>> CM> A generational GC would be great.  There has been talk of
> including one
>> CM> in the next version of the Ruby interpreter.  However C
> extensions also
>> CM> pose a problem here as well - it seems creating a write barrier
> that
>> CM> works with C libraries not written originally with Ruby in mind
> will be
>> CM> very difficult/slow.
>>
>> This shouldn't be a problem. As long as you don't pass ruby values
>> into the c libraries as 'user data' the data space can be separated
>> very well. If you must pass some 'user data' into the lib simply use
>> a proxy pointer, an keep the ruby object into a gc known address
> space.
>> A hashtable with all ruby objects referenced from the c lib is a good
>> idea here.
>
> I am no expert on GC's, so maybe my questions are bogus, but how would
> the GC 'know' which allocated regions to put behind the write barrier?
> For example with the Array class how would the GC know to put
> RARRAY(ary)->ptr behind the write barrier if ary made its way into an
> older generation?
> Would the memory allocation api (ALLOC_N,etc) have to be changed?
> Could this be determined by when the allocation was made?

I am not a VM expert, but I have overheard the Smalltalk VM guys (4 of 
them from different VMs in the same room!) talk about how write 
barriers can be efficiently implemented by reserving special areas of 
memory, choosing a certain region as your protected region, then using 
pointer address comparisons.

--Peter

--
There's neither heaven nor hell, save what we grant ourselves.
There's neither fairness nor justice, save what we grant each other.