[ruby-core:27478] Re: better GC?

Eero Saynatkari wrote:
> Excerpts from Paul Brannan's message of Thu Jan 07 21:53:34 +0200 2010:
>> OTOH the dynamic language space is becoming more competitive every year,
>> and it would be a shame to see ruby fall behind because it has to remain
>> backward compatible.
>>
>> Hypothetically, if ruby could give up backward compatibility with
>> existing extensions, would the problem become any easier?
> 
> Rubinius is also compatible with existing extensions*
> and, as mentioned previously, uses a more advanced GC.
> 
> I propose that it is better to spend effort on Rubinius
> whether developing or testing it for your purposes than
> it is to try to bolt various things onto MRI. This goes
> for many recent proposals here, but since this is the
> topic at hand...
> 
> 
> * That is, a C API identical to MRI's is provided. Only
>   recompilation needed, except for the cases where some
>   function/whatever has not yet been defined because it
>   has not been needed. If you have C exts, try them and
>   report any missing things so they can be added.
> 
> 

FFIs complicate GC.  There are numerous papers that assert that a simple 
hemispace copying collector out-performs generational collectors or 
other more complex collectors.  For example, efforts to parallelize 
collectors require read or write barriers or complex locking.  Copying 
collectors usually require additional pointer redirection for C code 
that has "references" to objects allocated from GC.

This is why conservative collectors (like MRIs) are popular with GC'd 
languages that leverage C code - the FFI is "dumb" and the allocator 
needs to assume the code behind the FFI is "dumb" and the language does 
not distinguish object "references" on opposite sides of the FFI.

Maybe we need to start abstracting Ruby implementation internals from C 
in a way that doesn't limit the GC implementation -- like JNI when Sun 
realized how poorly conservative collectors perform for 
long-running/large Java processes.  All Java implementations support JNI 
and not all Java implementations use the same GC technology.

> Eero
> --
> Magic is insufficiently advanced technology.
> 
>