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

On Mon, Jan 11, 2010 at 4:20 PM, Charles Oliver Nutter
<[e-mail]> wrote:
> 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 =
in a
>> way that doesn't limit the GC implementation -- like JNI when Sun realiz=
ed
>> how poorly conservative collectors perform for long-running/large Java
>> processes. =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.

I think that you are correct sir!

> 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.

This would be good.

I'm not sure whether the API ultimately needs to be binary compatible,
or that a macro-based API would be as good.

If I'm not mistaken the MRI extension API macro implementations
changed between 1.8 and 1.9, certainly some of the 'VM' data
structures did, meaning that extensions needed to be recompiled.

Back when we were flogging 'enterprise' versions of Smalltalk and Java
at IBM, maintaining binary compatibility of interfaces was important
because we didn't necessarily want to ship all the source, and folks
wanted to write (and ship) proprietary extensions.  Given the
open-source nature of Ruby and much of the world today, I'm not sure
that this is such a firm requirement.

--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale