Gardens Point Ruby.NET internals interview

Gardens Point Ruby.NET compiler, recently released version 0.8 , and is an existing option for running Ruby code on the CLR. The latest release made it possible to access code written in other languages from Ruby and vice versa. Since interoperability is an important topic for all Ruby runtimes for the CLR or JVM, we talked to John Gough, of the Ruby.NET team.

First off, John shares some implementation details about how Ruby.NET handles Ruby and .NET objects:

The interoperability depends on the particular choices that have been made in the representation of objects in Ruby.Net. Most objects that are *defined* in Ruby have CLR types that derive from Ruby.Object. Such objects have a field that points to the "Class" object that holds the dictionary for the object's type. However, objects of some built-in classes such as FixNum, True, False, are represented by a bare CLR object that boxes the raw value.

Method dispatch starts by calling a static "ClassOf" method with the object as argument. In the case of objects that derive from Ruby.Object this returns a reference to the class object for the Ruby class, while for FixNums the runtime returns a reference to the known class descriptor for the FixNum type.

Now, here is the payoff: ClassOf doesn't expect interop objects to be wrapped, so that if an object isn't a derivative of Ruby.Object, and isn't one of the built-in types, it must be an interop object. A global cache holds a mapping from CLR class to the Ruby class object that wraps the method calls on the interop class.

So when an object of a CLR class is met for the first time, the object is left unwrapped, but a Ruby class descriptor is created that makes the magic work. The available methods are discovered on demand, using reflection. There are still unresolved issues for such things as overloaded methods, although for some small subset of calls the argument types can resolve the binding.

There are some features  that aren't handled yet, such as reference parameters. John explains:

Another limitation of version 0.8 is the inability to deal with CLR methods which have reference parameters. This is not necessarily a show-stopper, it is just that we have not got to it yet. This is Wayne's [Kelly] call, but I expect that the reference parameters will end up being passed by copying. There is a lot of plumbing code required to make this work because on the CLR side byref arguments need to be of exact type ... rather a foreign concept for Ruby!

Note: Wayne Kelly is also part of the Gardens Point Ruby.NET team.

The compatibility and performance are on the TODO list. John:

As noted in the release notes, we still have not done anything at all about optimization, although we have tried to avoid any design decisions that will get in the way when we get serious about performance. We are very close to meeting our correctness targets, and will switch into speed-demon mode one we get there. In particular, we are not doing any call-site caching of method bindings, which is probably the single biggest performance boost in the whole dynamic language implementation space.

Community contributions are considered for the future of Ruby.NET. John explains the plans for the near future: 

We intend to continue on the project at least until the end of this year. We expect to open up the project to contributions when we reach version 1.0.
 This is just one project among several for Wayne [Kelly] and I. We both have responsibilities to the Microsoft-QUT eResearch Centre, see https://www.mquter.qut.edu.au, as well as ongoing work for other language tools, see http://plas.fit.qut.edu.au/projects, and other important stuff like a refresh of "Compiling for the .NET Common Language Runtime", John Gough,Prentice-Hall PTR, 2002.

For more information about the Gardens Point Ruby.NET compiler see this  Channel 9 interview with Wayne Kelly was recently interviewed.