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

On Thu, Jan 7, 2010 at 4:09 PM, Kurt Stephens <[e-mail]> wrote:
> Maybe we need to start abstracting Ruby implementation internals from C i=
n a
> way that doesn't limit the GC implementation -- like JNI when Sun realize=
d
> how poorly conservative collectors perform for long-running/large Java
> processes. =C2=A0All Java implementations support JNI and not all Java
> implementations use the same GC technology.

To be honest, I think this is the *only* path forward for MRI.
Slavishly supporting the current extension API doesn't really help
anyone that much (the good extensions everyone uses are being mainted
and could be updated to a new API), and makes it almost impossible to
optimize certain aspects of MRI.

Lots of people hate JNI, but it's a far less invasive way to write
extensions...and a lot of the cumbersome parts are by design. You
should not be able to get direct pointer access to object internals,
nor should you ever expose the structure of an object's memory layout.
Macros like RARRAY and RSTRING should be abolished in favor of
API-driven access (or opt-in "give me a copy of this array and then
put it back" functions). It should not be necessary to scavenge the C
stack to find live references. All these things make it harder to
improve MRI and almost impossible to implement the C API on other
runtimes (or at least, impossible without incurring large performance
penalties).

We are interested in supporting a C API in JRuby, but we will not
support any API that gives you direct access to pointers or object
structures. We'll work with Rubinius and MRI folks to come up with
replacement APIs, but any existing extensions that need unsafe access
will not work. If it's worthwhile to have C extensions that work with
many different runtimes/GCs/threading models, these API changes are
not really negotiable.

- Charlie