MacRuby - Ruby 1.9 ported to Objective-C

Posted by Werner Schuster on Mar 05, 2008 07:00 PM

Community

Ruby

Topics

Scripting,

Performance & Scalability,

Programming

A new project by Apple aims to improve Ruby on MacOS X. The MacRuby project is a port of Ruby 1.9 to the Objective-C runtime.

We talked to Laurent Sansonetti of the MacRuby project to find out what the project is about and how it works.

InfoQ: Is MacRuby an Apple-sponsored project?

Laurent Sansonetti: MacRuby is a free software project created by Apple. Currently the people around the project are Apple employees, though we definitely want to accept outside contributions, which is why we decided to open the project development on MacOSForge, and work on it in a public way.

InfoQ: You based MacRuby on Ruby 1.9/YARV. How much work was it to go from vanilla Ruby 1.9 to MacRuby? Was it mostly about changing object creation? (from Ruby's way to using Objective-C objects). What else had to be changed?

Laurent Sansonetti: The Ruby object data structure had to be modified to conform to the Objective-C object data structure, so that a Ruby object can be casted at the C level as an Objective-C object.

Then, the object allocator was modified to use the Objective-C one instead, which means that all objects (Ruby and Objective-C) are allocated from the same memory pool.

Finally, the traditional Ruby garbage collector was removed and instead we use the Objective-C garbage collector. This change wasn't very easy because the collector runs by default in generational mode, and expects you to appropriately set "write-barriers" every time you register an object in the object store, because it collects young generation of objects based on this information.

InfoQ: How does the creation of the Objective-C classes, that represent Ruby classes, happen? Are they all created at runtime dynamically?

Laurent Sansonetti: The Objective-C classes are created at the same time you define the Ruby classes. Reciprocally, when you access an Objective-C class from MacRuby, it will lazily import it in YARV.

InfoQ: On the Ruby objects, are the Objective-C methods visible?

Laurent Sansonetti: Yes, and vice-versa, Ruby methods are also exposed in the Objective-C world.

InfoQ: A topic of debate in the Ruby space is ObjectSpace. JRuby 1.1 has deactivated it by default. Do you know how Objective-C can do ObjectSpace functionality without a performance hit?

Laurent Sansonetti: All MacRuby objects are allocated from the same memory pool, more precisely a malloc zone (the /usr/include/malloc/malloc.h header file has more details). It is therefore very easy to walk through the zone and yield all objects in it. This functionality comes for free.
However, please note that calling ObjectSpace#each_object is significantly slower in MacRuby than vanilla Ruby, because it will return *all* objects, including pure Objective-C objects that are created by frameworks you require!

$ ruby -ve "p ObjectSpace.each_object {}"
ruby 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0]
310

$ /usr/local/bin/ruby -ve "p ObjectSpace.each_object {}"
MacRuby version 0.1 (ruby 1.9.0 2008-02-18 revision 0)
 [i686-darwin9.2.0]
8759

$ /usr/local/bin/ruby -ve "framework 'cocoa'; p ObjectSpace.each_object {}"
MacRuby version 0.1 (ruby 1.9.0 2008-02-18 revision 0) [i686-darwin9.2.0]
48425

InfoQ: What's the compatibility situation? I saw that Strings are based on NSStrings - are there any compatibility problems with that?  Are native extensions compatible yet?

Laurent Sansonetti: Currently the Ruby String class just inherits from NSString, to perform fast String to NSString conversion. So there is no compatibility problem at the moment.

However, in the very near future, we plan to re-implement the Ruby primitive classes (String, Array and Hash) using their CoreFoundation equivalent (CFString, CFArray and CFDictionary), to unify functionality but also to be able to perform costless conversion between both runtimes. Because we internally noticed that in a typical application, most of the objects that cross the runtime are primitive types.

This change might introduce some compatibility problems, however we will do our best to keep everything compatible with 1.9, and also C extensions.

InfoQ: What are the plans for MacRuby's future?

Laurent Sansonetti: The primary goal of MacRuby is to allow developers to write Cocoa applications that perform extremely well in Ruby, which is not possible with RubyCocoa, the technology we introduced on Mac OS X Leopard (and that we will still continue to support). In order to perform that goal, we still have some work to do.
We also want MacRuby to perform well on other use cases too. The current changes, but also the changes we plan to introduce soon, will definitely impact them.
We will release a milestone plan soon, as well as a first release! Stay tuned.

Check out the MacRuby project or take a look at MacRuby's source code at MacOsForge. For Laurent's announcement of MacRuby on the ruby-core list and the subsequent discussion about features such as the special syntax for keyed arguments. For more details on how MacRuby works, see the HowDoesMacRubyWork wiki page.

• Older >