From: Rick DeNatale Date: 2010-01-12T07:53:43+09:00 Subject: [ruby-core:27553] Re: better GC? On Mon, Jan 11, 2010 at 4:20 PM, Charles Oliver Nutter wrote: > On Thu, Jan 7, 2010 at 4:09 PM, Kurt Stephens 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 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. > > 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. -- 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