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?

>
> A little bit more overhead and it breaks all larger current binary
> extensions, but i think we must face the fact that Ruby 2.0 will give
> as a lot of code breaks anyway.
>
> --
>  Best regards,                        emailto: scholz at
scriptolutions dot com
>  Lothar Scholz                        http://www.ruby-ide.com
>  CTO Scriptolutions                   Ruby, PHP, Python IDE 's