Recently, our very own Rubinius officially joined the ranks with a 1.0 release. We are excited to see folks trying it out. All the feedback and issues reported have been a great help. Many people are reporting that their apps "just work".

With all this great news, the Ruby world looks rosy indeed. However, we can make Ruby even better. To do so, we need your help. You may not realize this, but the quality of the Ruby code you write can have a significant impact on how great we can make Ruby. I'd like to share some tips about how you can improve your Ruby code while helping us make Ruby better too.

0. Rubinius

Rubinius is a completely new implementation of Ruby. When Evan Phoenix started Rubinius, he put some stakes in the sand. Rubinius has a modern, bytecode virtual machine, a cutting-edge garbage collector, a just-in-time (JIT) compiler utilizing the awesome LLVM project, and a Ruby core library and bytecode compiler written in Ruby. We are only just getting started with 1.0. We have a whole list of features coming, including support for Windows and Ruby version 1.9, as well as improvements to the JIT compiler that should make Ruby several times faster, and removal of the global interpreter lock (GIL) so that your threads will execute Ruby code concurrently.

Rubinius does a lot of things differently than MRI under the covers. As Rubinius has grown up, we've definitely seen a wide cross-section of Ruby code while working on features and compatibility. The tips for writing better Ruby code below are based on some of the challenges we have faced.

1. Sending Messages

Rubinius is unique among the various Ruby implementations in that it implements the Ruby core library primarily in Ruby. Even the primitive methods, operations implemented in C++ that must access the virtual machine directly, appear to other Ruby code as normal Ruby methods. Importantly, calling these primitive methods from Ruby code is like calling any other Ruby method.

Early on in the Rubinius project, a lot of attention was focused on the idea of Ruby in Ruby. This was a good idea for several reasons, one of which being that Ruby is a more elegant and expressive language than C or Java, and that Ruby programmers tend to understand Ruby code pretty well. This familiarity with Ruby makes Rubinius easier to develop and maintain, and more approachable for many Ruby developers. The validity of these reasons has been demonstrated in the life of the project. However, there are two other very important reasons that don't attract quite as much attention.

The first of these is performance. As Evan often points out, Ruby is the currency of the Rubinius VM. It understands Ruby inside and out. The VM knows how to find a Ruby method, how to look up a constant, and what it means for an object to reference another object. The Rubinius VM operates on a special representation of Ruby code. This representation is often referred to as bytecode and is essentially a stream of instructions for the virtual machine. The JIT compiler, which can significantly improve Ruby performance, also operates on bytecode. What this means is that to the JIT, your program and the Ruby core library look an awful lot alike. So much, in fact, that the JIT compiler can mix them all together, which gives the optimizer much greater opportunity to generate really fast code.

The second reason is the consistency and elegance of an object-oriented language. When the Ruby core library is written in Ruby, you call a Ruby method, well, by calling a Ruby method. That may sound redundant, but I assure you, it is not. In MRI, for example, with the Ruby core library written in C, the code will often call directly to a C function rather than dispatching normally through Ruby method calls. What this means for you is that MRI may invoke "Ruby" functionality without engaging you in the conversation at all. That inconsistency may prevent you from using simple and elegant object-oriented code that extends the functionality of core classes.

In contrast, when functionality is invoked through normal Ruby dispatch, your code can be elegant and participate in the process. However, this is a significant double-edged sword, as we have become painfully aware of in Rubinius. When we implement all the complex behavior of the core library in Ruby, it's quite possible to do something crazy, like remove all the Ruby methods we need to make an object work! That is pretty crazy, right? Fortunately, in this coding wild west, there is a very important principle that can lend some law and order.

2. Liskov Substitution Principle

You may have heard this term tossed around in discussions. If you haven't, don't worry, we'll delve into this fairly intuitive idea. If you have, I hope to renew your commitment and respect for this principle.

So, what are we talking about here? Barbara Liskov and her collaborators were concerned with how to write reliable object-oriented software. As you know, one of the principle ideas in class-based object-oriented languages is inheritance, or the relationship between a class and its subclasses. What sort of rules should govern this relationship? What should we expect when we use a subtype in place of a supertype in our program? These are the questions that Barbara Liskov and others were pondering.

What they proposed is referred to as the Subtype Requirement, which they defined as:

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

(see Behavioral Subtyping Using Invariants and Constraints, by Barbara H. Liskov and Jeannette M. Wing.)

Let's consider this in terms of some Ruby code. Suppose you have this class in your program:

  class FancyArray < Array
    def initialize(size)
       # ...
    end
  end

What is wrong with this picture? Well, in my Ruby code, I can do x = Array.new. But what happens when I attempt to use the FancyArray class in place of Array? If I do x = FancyArray.new, I will surely get an ArgumentError exception because FancyArray requires that I pass one argument when calling the new method.

Let's phrase this in terms of the Subtype Requirement: Let x be an instance of Array. Then q(x) = the arity of the initialize method is -1. Let y be an instance of FancyArray, which is a subclass of Array. Then q(y) = arity of the initialize method is -1 by the Subtype Requirement.

Now let's relate the above to Ruby code and check if the Subtype Requirement holds:

irb(main):001:0> x = Array.instance_method(:initialize).arity
=> -1
irb(main):002:0> y = FancyArray.instance_method(:initialize).arity
=> 1
irb(main):003:0> x == y
=> false

It is clear from this that FancyArray does not conform to the Subtype Requirement. Consequently, code that expects to use an Array will not function correctly when a FancyArray is substituted. It's important to also note that the Subtype Requirement applies to any observable property of the object. The example used in the paper is of a Stack and Queue. Both classes may provide push and pop methods, but the semantics of the methods are quite different between the two classes.

Now, you may say, "But, I have a very good reason for requiring an argument to new." Well then, I would venture to say you have an important reason to consider the difference between composition and inheritance for designing your program.

3. Composition versus Inheritance

Of the three object-oriented principles—inheritance, encapsulation, and polymorphism—inheritance has been so abused there could be a 12-step program devoted entirely to it. Fortunately, the remedy for inappropriate use of inheritance is quite simple: compose your objects of other objects.

Inheritance models an is a relationship, while composition models a has a relationship. If your object is a String, then it will do all the normal String things just as a String would do them. This is very important. It needs to do String things not just externally, when you call the methods, but internally, when the other String methods call each other. Is your FancyTemplate class really a String? Then, for example, I should always be able to request its length. However, your FancyTemplate instance probably doesn't have a length when it is being built. Therefore, String methods that may be employed during the construction phase could be highly confused. In such case, I suggest your FancyTemplate has a String internally, and it can be urged to give you a representation of that String at some point in time. Yet, it is not a String from the perspective of inheritance and conforming to the Liskov Substitution Principle.

Only you can tell whether your model is best represented by inheritance or composition. When designing your classes, be sure to consider the view from inside and out. If you are contorting your methods to act like the class you are inheriting from, perhaps your class only has one of those things, rather than being one of them. Most importantly, remember that you are not the only kid on the playground.

4. Playing Nicely

This is more about general advice than specific admonitions. We are lucky to have such a powerful, expressive language in Ruby. Opening a core class to patch a method is tremendously useful and powerful. However, remember that with great power, comes great responsibility.

First and foremost, simply be conscious of what you are asking Ruby to do for you. I used this example earlier, and I'm going to repeat it because in Rubinius we have encountered this more times that we can count. Ruby is an object-oriented language. You cause computation to occur by sending messages to an object. How can the object work if it has no methods? (I say with my best Zoolander impersonation). If your code does:

  class SomeClass
    instance_methods(false).each { |m| undef_method m }
  end

you are (most likely) doing it wrong. There are many variations on this theme, but they all share the same problem: the assumption that those methods you are removing are as superfluous as Johnny's appendix. I assure you, we don't randomly add methods to classes in Rubinius. Again, your code may work fine in MRI when you do this because MRI calls C functions on that object behind your back with impunity. But, we do want to have nice things, right? If you ever wonder what consequences your code may have, just drop into the #rubinius channel on freenode. We will happily discuss it with you.

A related problem occurs when code inherits from a core Ruby class and redefines one of the core methods. When the core classes are implemented in Ruby, the methods may depend on one another to perform their tasks. For example, in Hash it would not be entirely unreasonable for each_value to be implemented in terms of each. Well, not unreasonable, that is, until you try to run REXML in the Ruby Standard Library. REXML has an Attributes class that inherits from Hash. The Attributes class then implements an each_attribute method. For good measure, it overrides each to use each_attribute. And each_attribute calls each_value. Waiter, I believe there's a StackError in my Attributes. The moral of the story: the two edges on this wonderful Ruby sword are sharp. It does take extra work to consider how methods on a particular class interact with one another; to some extent, this is an implementation detail. However, it's something to be aware of when you write code. Of course, you can always browse the Ruby implementation of the core classes in Rubinius.

Playing nicely is more than being conscientious about how you write your own code. It's also important to consider how you use code others have written. Your code should not depend on implementation details of the classes and libraries you use. However, it's often hard to know what those implementation details are. Often the dependency will be subtle and implicit. Your code will appear to work fine in MRI but break in one of the alternative implementations. There is no general solution to this problem, but you can usually avoid it by checking the assumptions your code makes about the other code it uses. One example of this is mutating a collection in the block passed to an iterating method. Consider the following code:

some_hash.each { |key, value| some_hash.delete(key) if fancy_test(value) }

Hash is a fairly complex data structure and this bit of code can have very different behavior depending on how Hash is implemented. Thankfully, Matz has explicitly said this behavior is undefined.

5. Neighborly C Extensions

While playing nicely in Ruby code is important, it's also very important when writing C extensions. These are programs typically written in C/C++ that directly access the C functions that MRI uses to implement Ruby. You probably regularly use one or more gems or libraries that are partially implemented by a C extension. C extensions are often used to access native libraries from Ruby, for example, when writing database adapters.

C extensions are not the only way to access native libraries from Ruby. There are also the FFI and DL libraries. Rubinius was the first implementation to popularize the use of the foreign-function interface (FFI) library for accessing native code. In fact, vital pieces of the core library in Rubinius are implemented via FFI, which is a modern implementation of DL, the dynamic load library that MRI has included for years. There are now quality implementations of FFI available on both JRuby and MRI.

FFI is generally the preferred way to interface with native libraries. The benefits include not needing a C compiler and being able to harness the speed or power of a native library while writing pure Ruby code. However, there are still two core use cases for C extensions: 1) when the data marshaling through the FFI layer imposes too large a performance cost; or 2) when your code already relies on an existing C extension. These use cases are hard to get around. Fortunately, we have put a lot of effort into getting C extensions working quite well on Rubinius. In fact, many C extensions just work.

However, there is one particular problem with some C extensions that limits our ability to support them: some have explicit dependencies on MRI data structures, for example, RHash. Depending on a data structure your code does not control makes your program vulnerable to breaking if the other code changes its implementation. Unfortunately, the C programming language doesn't do much to enforce good practices here. If the C compiler can see a structure or function in a header file, you are free to use it in your program. Yet, just because you can, does not mean you should. Instead, you should always use a function interface (also known as an API) to access the data. Treat data structures that are not your own as opaque.

Of course, that is the ideal world. MRI cannot foretell every use case that a C extension may have. So some of these problems are simply the result of people being more creative than the MRI developers imagined, which is mostly a good thing. In version 1.9, MRI is enforcing the use of API's over raw struct access. For example, rather than using RSTRING(obj)->ptr, your code should do RSTRING_PTR(obj) instead. Since Rubinius is compatible with MRI version 1.8.7, we still support both forms in this case. However, to make your code robust and portable, you should use the RSTRING_PTR API.

One thing Rubinius does not support is code like RHASH(obj)->tbl that accesses the RHash struct directly. This is partially because, in Rubinius, Hash is implemented entirely in Ruby. However, most C extension code needs to do something like iterate over the entries rather than just access the structure. In this case, the rb_hash_foreach function is available, so it's quite easy to change a C extension so it will run on Rubinius. In fact, a number of C extensions have already been updated in this way. If you encounter a problem with a C extension, please file an issue for it.

We understand there are valid use cases for writing C extensions. While Rubinius is implemented very differently than MRI, we want your C extensions to be able to run in Rubinius and we have worked hard to ensure that most C extensions do run. If you encounter cases where there is no function API to work with MRI data, let us know. We can collaborate with Matz and the MRI developers to add such APIs. That way, you can help us help you to make Ruby better for everyone. Win!

Ruby is a terrific language and with your help, it can be even better. Do you have any tips for writing better Ruby code? Please, let us know.

If you are new to Rubinius, you may find these previous posts informative:

• Making Ruby Fast: The Rubinius JIT
• Improving the Rubinius Bytecode Compiler
• Compiling Ruby: From Text to Bytecode
• 5 Things You'll Love About Rubinius
• Rubinius: The Book Tour

In this post, I'll explain what I've been doing and how it relates to getting Rubinius ready for 1.0. We recently released version 0.12 and we're going to be doing releases about every two weeks. If you haven't built Rubinius yet to check it out, head over to our download page and get started!

Principles

Before we get into code examples, let's lay the groundwork and review some general principles for writing software. We learn early in computer science that programming involves a series of trade-offs. There's always the the classic trade-off between execution time and storage space. If we write a function that saves each value it computes, it can return the saved value instead of re-computing it, but saving the value requires using memory or disk space. A function that computes millions of values would potentially need millions of storage locations.

While speed versus space is probably the most well-known classic trade-off, there are others. With a nod to Philip Kapleau, here are the three pillars of developing Rubinius: Code Quality, Compatibility, and Performance, or QCP. These interact in complex ways and there's no simple way to prioritize them. By compatibility, I mean conforming to the same behavior as MRI (or Matz's Ruby).

These three characteristics are interdependent. Clean, high-quality code enables working more quickly on compatibility. When code is behaving correctly, it's easier to profile and improve performance. Good performance, in turn, can make it easier to identify and fix compatibility issues. Quality code is easier to understand and work with when improving performance. These feedback loops push each of these code characteristics forward. The converse is also true. At times, it may be tempting to sacrifice quality to improve performance, but quick and dirty never pays off in the end.

To sum up, these are the goals we're pursuing: simplify and improve the bytecode compiler code, improve performance, make it simpler and easier to bootstrap Rubinius, and ultimately make it easier to fix compatibility issues running fantastic Ruby software, like your Rails applications.

Parsers and Compilers

There's a certain mystique that surrounds compilers. Rather than just accept the mystique, let's take a peek behind the unicorns and dragons and check out the simple gears and pistons that make it all work. In general terms, a compiler is a process for converting data from one form into another. In the specific case of Ruby, the compiler converts text in the form of Ruby syntax, into operations performed by the computer's CPU.

In discussing compilers, two rather distinct operations are often lumped together, namely, parsing and code generation. Parsing is the process of converting the source code into a data structure that the compiler can process to produce code that the computer, or a virtual machine, can execute, to perform computation. There are specific issues with each operation so let's look at them separately.

A. The Parser

Humans are the most adept and complex parsers in existence. One natural language can choke up a powerful computer, but humans typically handle one and sometimes several languages with relative ease. Not just the words or sounds of a language either, but also the intonations, facial expressions and body language that accompany even the simplest communications.

Compared to natural languages, programming languages are very simple, but even the simplest languages can be challenging to parse. Syntactically, Ruby is a rich and complex language. We love it for the expressive programs we can write—but parsing Ruby is hard. Every Ruby parser in the Ruby implementations that I know of are based on Matz's parser. From the beginning, Rubinius has used a directly imported version of Matz's parser with a few minor modifications.

Detour—Bootstrapping

Before continuing, we need to take a short detour. I'll be writing a post on the Rubinius bootstrapping process in the future, but I'll start by briefly describing part of the problem here.

The Rubinius bytecode compiler, and most of the Ruby core library (classes like Array and Hash), are written in pure Ruby—and herein lies the challenge. The Rubinius VM interprets bytecode. To run the Rubinius compiler, it needs to translate the Ruby source code for the compiler into bytecode, but to do so, Rubinius needs to run the compiler. You can probably see where this is heading: around and around without getting much done.

That is the essence of the problem of bootstrapping. To break this loop, we need to insert a process that does not depend on Rubinius. In other words, we need something that's not Rubinius to compile the core library and bytecode compiler so that Rubinius can load the bytecode and run the compiler. Then Rubinius can compile its own compiler and core library.

One way to do this would be to load the Ruby source code in MRI and use the ParseTree gem to extract the MRI parse tree as a recursive array of symbols and values, something also known as an S-expression or sexp. But, since you can't change the MRI parser without impacting its run time behavior, Evan Phoenix wrote the sydparse gem.

This gem is essentially a C extension combining the MRI parser with the sexp generation code from ParseTree. The gem enabled Evan to modify the parser if desired and get the parse results as a sexp. The sydparse gem is basically built into Rubinius currently under the vm/parser directory.

For example, try the following code:

$ bin/rbx
irb(main):001:0> "a = 1".to_sexp
=> s(:lasgn, :a, s(:lit, 1))

So, with the String#to_sexp method, we have something that will take Ruby code and transform it to a data structure that should be fairly easy for a computer to process. And that is precisely how the early Rubinius bytecode compiler worked: it processed sexps into bytecode. It didn't matter whether the sexps are output by sydparse running in MRI or by the Rubinius built-in parser. With that, a big part of bootstrapping was solved.

Back to the Main Road

So we've got a compiler that processes sexps to bytecode and it runs in both MRI and Rubinius. Everything sounds copacetic—what's the trouble, you ask? Well, compiling Ruby is hard, too.

To make the process more tractable, Evan rewrote the compiler so that the sexps are processed into an abstract syntax tree (AST) of Ruby objects. Each object has a #bytecode method. To generate bytecode, start at the root of the tree and visit each node, calling the bytecode method for the node.

For perspective, let's enumerate all the stages in the compiler. I'm glossing over a few details here, but you'll see the basic picture:

1. parse tree: A tree of C data structs created by the MRI parser.
2. sexp: A recursive array of symbols and values created by processing the MRI parse tree.
3. rewritten sexp: The form of the sexp after certain structures are normalized to make converting the sexp simpler.
4. AST: The abstract syntax tree of Ruby objects created by processing the rewritten sexp.
5. bytecode: A stream of instructions that the Rubinius VM can execute.
6. compiled method: The bytecode packaged with some additional information like the names of local variables and the amount of stack space needed when the compiled method runs. A typical Ruby source code file compiles to a tree of compiled methods.
7. compiled file: The Rubinius VM can execute the compiled methods directly. But to avoid having to recompile them, the tree of compiled methods is serialized to a compiled file on disk. Rubinius can read the compiled file to recreate the tree of compiled methods in memory.

That's a significant number of stages and it's not hard to see where we can simplify to improve the process. Those sexp stages appear to just be passing data along. In fact, they require creating a lot of additional objects, time to process, and some seriously complex code to process them. The latter has a significant, negative impact on code quality.

S-expressions are just data, dumb and brittle. They only have form (e.g. [:x, :y] versus [:x, [:y]]) and position (e.g. [:alias, :x, :y] versus [:alias, :y, :x]) to encode information. If you wanted to add, for example, a line number to every sexp, you'd need to put the information in a form and at a particular position in every sexp, or you'd need to wrap every sexp in one that encodes the line number. The simplicity of sexps is beguiling, but you know what they say when all you have are s-expressions... Everything looks like function application.

On the other hand, we have this rich, object-oriented language that makes it trivially easy to create objects that conform to a consistent interface. We want to get from the Ruby text to Ruby objects as quickly, and simply, as possible.

One option would be to write the compiler so that it processes the MRI parse tree directly into bytecode. Unfortunately, that would require either rewriting the compiler in C (not gonna happen) or making the C data structs available in Ruby. The latter option sounds promising. We could translate the parse tree directly into an AST.

Melbourne

Enter Melbourne, a C extension that can run in MRI or Rubinius and process the MRI parse tree directly into an AST. In case you were wondering, it was named in honor of Evan's sydparse gem, and some rowdy Aussie developers we know.

In Melbourne, each node of the MRI parse tree is processed using a mechanism we all know and love: a method call. At each parse tree node, all children are processed by recursively calling the process_parse_tree function (see lib/ext/melbourne/visitor.cpp). At a leaf node, there are no children to create, so an appropriately named Ruby method is called on the Rubinius::Melbourne instance that is passed to process_parse_tree.

Once all of a node's children are created, a method is called for the parent node, passing along the objects that were already created for the node's children. You can see the result of this process by running the following command:

$ bin/rbx -r compiler-ng -e '"a = 1".to_ast.ascii_graph'
LocalVariableAssignment
  @line: 1
  @name: a
  FixnumLiteral
    @line: 1
    @value: 1

In lib/melbourne/processor.rb, you can see code like the following. Whenever a local variable assignment parse tree node (lasgn) is processed, this method is called and the LocalVariableAssignment AST node is created. Pretty straightforward.

def process_lasgn(line, name, value)
  AST::LocalVariableAssignment.new line, name, value
end

One of my goals for improving the code quality in the compiler was to replace the use of conditionals by creating more explicit nodes in the AST. Sometimes code suffers from what I'd call conditionalitis, or inflammation of your conditionals (sounds painful, huh?). That's where you maintain a lot of state and use conditionals to figure out what to do.

An alternative is to create different forms of things that just do what they are supposed to do. Simply avoiding using conditionals is not really an option, but where they're used can have a big impact on code quality. It's can be hard to understand by just looking at the code why one branch or the other would be taken when the program is running, but when the conditional results in different forms being created, it's much easier to comprehend how the program will behave

For example, in MRI a.b = 1 and a[b] = 1 are parsed into the same parse tree node. But there are enough things that need to be done differently in the two cases that just creating different forms can make these tasks simpler and more explicit. The code in lib/melbourne/processor.rb for processing an attrasgn node looks like this:

def process_attrasgn(line, receiver, name, arguments)
  if name == :[]=
    AST::ElementAssignment.new line, receiver, arguments
  else
    AST::AttributeAssignment.new line, receiver, name, arguments
  end
end

B. The Compiler

By this point we have a fully formed AST that faithfully represents the Ruby code we started with. Emitting bytecode now is almost anticlimactic. Not really, of course, because there is plenty of work left to do. Just keeping track of local variables in methods, blocks and evals could take up a whole post, but the basic idea is really simple. Start at the root node and call the #bytecode method, walking down the tree until every node has been visited. All the details (and there are a lot of them) can be found in the #bytecode methods on the AST nodes (see lib/compiler-ng/ast).

Besides generating bytecode, there are other interesting things you can do simply by defining methods on the AST nodes and visiting them. I'll give you two examples. First, let's look at defined?.

# defined.rb
class A
  class B
  end
end

def x
  puts "hey there"
  A
end

p defined? A::B
p defined? x::B

If you run this code in Ruby, you should see the following output.

$ ruby defined.rb
"constant"
hey there
"constant"

This code illustrates something about defined?. It doesn't just check internal data structures. In some cases, like x::B, it must do some evaluation.

In Rubinius, we simply add a defined(g) method to any relevant AST node that takes an instance of the bytecode generator object and emits bytecode appropriate for evaluating the expression passed to defined?. Here is the full code for the Defined AST node.

class Defined < Node
  attr_accessor :expression

  def initialize(line, expr)
    @line = line
    @expression = expr
  end

  def bytecode(g)
    pos(g)

    @expression.defined(g)
  end
end

Rather than emitting bytecode, it's possible to simply evaluate the AST, performing actions when visiting each node. Rubinius has an evaluator for being able to write bits of code for which there is no simple Ruby syntax. The evaluator makes it possible to write directly in Rubinius assembly language (i.e. in the operations that the VM directly executes). Consider this example:

# asm.rb
def hello(name)
  Rubinius.asm(name) do |name|
    push :self
    run name
    string_dup
    push_literal "hello, "
    string_dup
    string_append
    send :p, 1, true
  end
end

hello "world"

If you run this in Rubinius, you should see the following output:

$ bin/rbx asm.rb
"hello, world"

Of course, this example is much easier to write in plain old Ruby. However, we use this facility in the Ruby core library. For example, in the Class#new method.

The basic idea is that a tree of Ruby objects representing Ruby source code is a powerful tool that can be easily extended to accomplish various tasks.

Compiler, Part Deux

Let's revisit the list we presented earlier of compiler stages. How do we coordinate those stages? What if we need to insert a stage? Well, by creating more things we can name, and on which we can define behavior.

You can see the various stages laid out in lib/compiler-ng/stages.rb. By default, each stage know which stage follows it. You create an instance of the compiler by specifying the starting stage and the ending stage. Each stage has an interface with the preceding and following stage, with the compiler object itself, and with the object that performs the work for that stage. For example, if the compiler will compile a String to a CompiledMethod, it will consist of the StringParser, Generator, Encoder, and Packager stages.

The goal was to create an API for the compiler that made it simple to use programatically in a variety of circumstances. For example, using the compiler internally to compile a Ruby file when #require is called or in a command line script like lib/bin/compile-ng.rb. The command line script may give the option to show the data structures as the compiler is processing them. Here's an example:

$ cat var.rb
a = 1
p a

$ bin/rbx compile-ng -AB var.rb
Script
  @name: __script__
  @file: "var.rb"
  Block
    @line: 1
    @array:
      LocalVariableAssignment
        @line: 1
        @name: a
        FixnumLiteral
          @line: 1
          @value: 1
      SendWithArguments
        @line: 2
        @name: p
        @privately: true
        Self
          @line: 2
        ActualArguments
          @line: 2
          @array:
            LocalVariableAccess
              @line: 2
              @name: a

============= :__script__ ==============
Arguments:   0 required, 0 total
Locals:      1: a
Stack size:  3
Lines to IP: 1: 0-4, 2: 4-14

0000:  meta_push_1
0001:  set_local                  0    # a
0003:  pop
0004:  push_self
0005:  push_local                 0    # a
0007:  allow_private
0008:  send_stack                 :p, 1
0011:  pop
0012:  push_true
0013:  ret
----------------------------------------

$ bin/rbx var.rbc
1

Take a look at bin/rbx compile-ng -h for more options and try this out on your Ruby code. It opens up a pretty exciting world of understanding.

A Final Note

Melbourne and the new compiler will both be enabled in the up-coming 0.13 release, so anywhere I've used compile-ng or compiler-ng in this post, will become just compile or compiler. Until then, all the code exists in the Rubinius Github repository, so you don't have to wait to check it out.

Thoughts? Questions? Leave them here!

1. We Take Out the Garbage

No one likes cleaning up after a messy roommate, navigating around piles of junk or restarting your app servers constantly because  memory use grows without bound.

The Ruby language has automatically managed memory. In other words, the programmer doesn't worry about manually deallocating the memory for objects. The memory manager is generally referred to as a garbage collector. However, not all garbage collectors are made equal.

Rubinius uses a generational garbage collector. Generational collectors are based on the idea that most objects live fast and die young. Generally, garbage collectors manage a collection (or heap) of objects. The generational garbage collector is a combination of two or more garbage collection algorithms.

An object is allocated in a heap based on the object's age. New objects are created in the young generation or nursery. If an object is still alive after the young generation collector runs a certain number of times, the object is promoted to the mature generation. The point of a generational collector is to reduce the amount of work the garbage collector has to do.

The Rubinius young generation uses a semi-space copying collector. The heap is split into two regions. Objects are allocated in one of the regions. When a region is full, all live objects are copied to the other region and new objects are allocated there until it is full. Allocations and collections continue in this flip-flop manner. The main advantage of this algorithm is that the collector only deals with live objects. If most of the objects are dying before the collector runs, it has much less work to do.

For the mature generation, Rubinius implements the Immix Mark-Region algorithm. The Immix collector has very fast allocation by simply incrementing a pointer rather than searching a free list. The Immix algorithm uses something called opportunistic evacuation for compaction.

Basically, it can move objects while marking the live objects. It uses the same incrementing-pointer allocation for objects that it is moving. The Immix paper is one of the most accessible academic papers on garbage collectors that you will find, so I highly recommend reading it.

There are two main things we still need to implement in the Rubinius garbage collector. In the young generation, objects like Bignum that use unmanaged memory internally have to be tracked down when they are no longer live so the unmanaged memory can be freed. Compaction for the mature generation also needs to be implemented.

2. We Take "Dynamic" to the Metal

We all know that Ruby is an extremely dynamic language. So why implement Ruby by statically compiling huge chunks of code that can never be changed while your program is running?

Dynamic compilation, or just-in-time (JIT) compilation, is a strategy for converting source code to machine code that defers the decision to compile until some point when the program is running. The JIT may run just before a method is executed for the first time or it may run after a method has executed many times. The latter case is called profile-based JIT and the trigger can be, for example, the number of times a method is called or the time it takes a method to run.

The primary advantage of dynamic compilation is that it can potentially use information from your running program to generate better machine code that executes faster. The whole point is to create a version of the code that does less to get the same task accomplished and thereby runs faster.

The way this is done is by trading flexibility for speed. There are two main pieces of runtime information the JIT uses: the type of the object being sent a message at a particular location, and the number of times a method is called.

The most powerful technique in the JIT toolbox is method inlining. Inlining is basically copying the body of a method directly into the code that is calling the method. However, it's not the copying that is the point. Once methods have been inlined, there is more code for the JIT optimizer to work on. Redundant computations can be eliminated. The more code the optimizer can see, the more effectively it can do its job.

In Rubinius, the JIT compiler takes bytecode that was generated from Ruby source code and compiles it to machine code using LLVM. Rubinius has a lot of Ruby code. In Rubinius, the Ruby core library is mostly implemented in Ruby code. This means there is a lot of room for the JIT to do its work and make your program run fast. If a part of your program uses Hash heavily, for instance, the Rubinius JIT can inline Hash methods directly into your code, potentially making those heavy used areas extremely fast.

3. We Play Nice

There are many C extensions written for Ruby. While Rubinius and JRuby have been pushing the idea of using FFI to work with C libraries from Ruby code, there are situations where a C extension can be a big help. With Rubinius, we realize it would be a barrier to adoption if your existing code did not just work. We want to play nice with existing code.

There are two main components for supporting C extensions. The first is the C-API. Rubinius is not implemented like MRI, so we have to provide special functions to shim the C-API (for example, rb_ary_new). A lot of these are implemented by just calling Ruby methods in our core library using rb_funcall.

The second component is a bit more complicated. In MRI, the garbage collector never moves objects. Some C extensions consequently assume that they can keep a reference to a Ruby object in some global data structure. These C extensions would not be able to work with Rubinius if raw memory pointers to objects were given to the C extension because the Rubinius garbage collector does move objects. Furthermore, the garbage collector cannot know everywhere the C extension may stash a pointer, so it cannot update the reference with the new address of the Ruby object after it is moved.

Rubinius implements an object handle abstraction. The C extension is given C++ pointers that never change. These pointers are actually handles to the real Ruby objects. When the garbage collector moves an object, the C extension doesn't need to know about it. The C-API functions take care of converting handles to object references before doing their work.

The trade-off is that some C extensions may be slightly slower, but the benefit is being able to run practically any C extension that exists. Having running code is a big step in migrating to using FFI when it is reasonable to do so.

Mongrel, BigDecimal, Readline, Digest, YAML/Syck are some MRI C extensions that currently run in Rubinius. In a future post, I'll discuss our new parser, which is a C extension based on the existing MRI parser.

4. We Are Organized

How a project's source code is organized, both at the file system and in the source itself, can be a help or hindrance to a programmer attempting to understand or contribute to the project.

The Rubinius project can be divided into roughly four main components. These divisions are reflected in the organization of source files in the file system.

The Ruby core library (Array, Bignum, Hash, etc.) is located in the /kernel directory. The alpha.rb file and the bootstrap, common, and delta directories are loaded in alphabetical order. The majority of the code is in the common directory. This structure is used to support bootstrapping and to make it possible to share the Ruby core library with other implementations. The implementation-specific code is kept in the bootstrap and delta directories, while the more general code is in the common directory.

The Ruby standard library in the /lib directory. Most of this code is imported from MRI. The C extensions are located in /lib/ext.

The virtual machine, which includes the bytecode interpreter, garbage collector, JIT compiler, parser, and C-API, is located in the /vm directory and its subdirectories.

The bytecode compiler is presently located in the /kernel/compiler directory, but this will be moving to lib/compiler in the near future. Again, I'll be telling you about the parser/compiler refactoring soon.

Even though the majority of the core library is implemented in Ruby, there are some things that cannot be done in Ruby. These primitive operations are implemented in C++. Every Ruby class that requires primitive support has a corresponding C++ class with the same name. For example, there is an Array C++ class that implements the primitives for Ruby Array. These C++ classes are located in the /vm/builtin directory.

The correspondence between class names makes it easy to find your way around the code and easy to understand the VM code that uses Ruby objects.

5. We'll Try Anything Once

The goal of Rubinius is to be a fully compliant Ruby implementation that is very fast, stable, and reliable. Applying cutting edge research to make this possible requires experimentation.

Over time, Rubinius has changed from using C to using C++, changed the way primitives are implemented, rewritten the bytecode compiler, changed the bytecode interpreter execution model from stackless to using the C stack, changed the way exceptions are handled, added a custom JIT compiler, and replaced that with an LLVM-based one--just to name a few things.

Each time we made a change, the benefits of changing significantly outweighed the benefits of not changing. However, changing is never easy. We have been continually restructuring the code during these changes to make it easier to implement new features because that is the best and fastest way to get innovation implemented.

Here's an anecdote about how easy it is to work with Rubinius: the other day Ari Brown, a 17-year old high school senior from New Hampshire who first started contributing to Rubinius over a year and a half ago, thought it would be interesting to add literate programming support for Ruby. You can see his branch here. It didn't really require that many modifications, but the cool thing is that Ari did it without any help from us. I think that speaks at least in part to the accessibility of the Rubinius codebase.

Do you have an idea you're itching to try out in Ruby? Clone the Rubinius repository and start hacking away. You get commit rights after your first patch is accepted. If you want to try something radical, you can push your work to a public branch. That way you can make your case by showing how it works in real code.

So that's it for my "good roommate" pitch. Feel free to get your parents' opinion before inviting Rubinius to stay the night. Once you get to know Rubinius, I'm sure it'll be a life-long friendship, and there's still time before Thanksgiving vacation to get your very own commit bit. As always, let us know what you areas of Rubinius you'd like us to better explain by commenting or finding us online.

Rubinius, which you've no doubt heard lots about over the last few years, is an implementation of the Ruby language written from scratch using cutting edge technology and the best industry research. Based on the questions we've received over the past few months, it's clear that a lot of folks are looking to learn more about the technologies behind the project. This is exciting because with so much written in Ruby, Rubinius positively begs Ruby developers to experiment and explore.

In this post I'll describe each of the basic parts of Rubinius, and provide some helpful links to books that I've found particularly useful in understanding how Rubinius is built.

Bytecode Virtual Machine (VM)

Similar to Java, Rubinius runs your Ruby source code by first compiling it to bytecode and then executing that bytecode on the virtual machine. It's reasonable to think of a virtual machine as a CPU written in software. Virtual machines can be optimized to run very fast, which is one of the advantages over an interpreter like that used in Ruby 1.8.

A great deal of research on virtual machines has been done in the past 30 years, starting with Smalltalk and SELF and continuing with Java. Evan's first prototype of Rubinius was written in Ruby and based on the Smalltalk-80 virtual machine. Understanding something about virtual machines is definitely the gateway to modern programming language implementations.

The Books:

• Virtual Machines: Versatile Platforms for Systems and Processes
• Smalltalk-80: The Language and its Implementation

Bytecode Compiler

Compilers are one of the most useful tools in computer science and have probably been researched more than any other area since the 1950s.

The Rubinius bytecode compiler is written entirely in Ruby. Every method defined in your Ruby source code is compiled into an instance of the CompiledMethod class. The compiled method contains a list of bytecodes that essentially provides a blueprint for how to carry out the computation described in the source code.

The Books:

• Engineering A Compiler
• Compilers: Principles, Techniques, and Tools
• Advanced Compiler Design and Implementation

Ruby Core Library

Almost all programming languages provide a library with useful data structures and other facilities. Some of the Ruby core library classes include Array, Hash, String, Regexp, Range, Float, Fixnum, Bignum, and Thread.

In Rubinius, this is again written almost entirely in Ruby with some VM-specific parts. For example, adding two Fixnums requires special VM support because Ruby as a language has no constructs for telling a CPU to access memory locations, treat them as machine integers, and add them together.

The algorithm is one of the most fundamental ideas in computer science. Basically, it is an ordered set of steps to perform to solve a problem or do some calculation. Data structures, like Array in the core library, are implemented using various algorithms. The algorithm used must provide the correct answer and must be reasonably efficient.

Working with the Rubinius core library is probably the easiest way to get involved since it's in Ruby! If you have experience with RSpec in your Ruby or Rails projects, you'll feel right at home using RubySpec to work on the core library BDD-style.

The Books:

• The Algorithm Design Manual, 2nd Edition

Garbage Collector

Taking out the garbage is a fact of life. Rubinius includes a precise, generational garbage collector with a moving semi-space collector for the young generation and an implementation of the Immix Mark-Region garbage collector for the mature generation.

The performance of the garbage collector can have a big impact on how fast your code runs. With the change to the Immix collector and some improvements to the young generation, the percentage of time Rubinius spends in the garbage collector during a full RubySpec run dropped from nearly 50% to around 10%. Further improvement in this area is possible.

The Books:

• Garbage Collection: Algorithms for Automatic Dynamic Memory Management

JIT Compiler

A Just-in-time compiler generates native machine code from your source code while your program is running. Typically, the JIT compiles the code based on feedback about which parts are getting used the most. The parts that have been JIT compiled often run quite a bit faster than the VM. However, in a language as dynamic as Ruby, the JIT compiler can usually produce much more efficient code after the VM has run and gathered information about the code.

Rubinius uses the LLVM Compiler Toolkit to implement the JIT compiler. The basic concepts from the compiler books above all apply here. Also, see the detailed LLVM documentation.

That's it for the book tour intro to Rubinius. I'll be giving a more detailed talk at OSCON 2009 titled Rubinius 1.0: The Ruby VM That Could. Hope to see you there, or visit us in the #rubinius channel on irc.freenode.net to get involved!

Ok sure, that comparison is hyperbole, but bear with me. Try this out in your irb session:

>> Float("0.5") == "0.5".to_f
=> true

That's reasonable enough. Imagine if it weren't true! But did you know that the Float() method converted the "0.5" text string to a Float object without calling the string's to_f() method?

What is the definition of Ruby in this situation? Is it that Float() returns a Float object for a validly formatted text string or that Float() does so without calling the string's to_f() method? Let's investigate the situation a bit more.

In Ruby, if you define an arbitrary object that you want to behave like a Float object, you define a to_f() method for your object. Then Float() will call that method on your object:

>> s = "0.5"
=> "0.5"
>> def s.to_f() 42 end
=> nil
>> floaty = Object.new
=> #<Object:0x5eb190>
>> def floaty.to_f() 0.5 end
=> nil
>> Float(floaty) == Float(s)
=> true

Now that is surprising. A lot of the elegance of Ruby comes from generally everything being an object. In some sense, floaty and "0.5" are just objects, so why does the Float() method treat them differently?

More importantly, should you rely on Float() not calling your string's to_f() method, or is that merely an implementation detail of MRI (Matz's Ruby Implementation)? This is the dilemma faced repeatedly by every alternative Ruby implementation.

Fortunately, we have a powerful tool to assist us.

The RubySpec project is writing an executable definition of the Ruby programming language using RSpec-style specs. The tremendous utility of the specs is that alternate Ruby implementations can run them to determine if they are building a compatible Ruby engine.

Presently, the specs contain over 33,000 precisely defined facets of Ruby behavior. The specs cover Ruby behavior across different platforms, operating systems, and versions of the Ruby language. The goal is to ensure that Ruby applications written to use the core Ruby features covered by the specs will run the same on any Ruby implementation.

RubySpec has been well-known in the community of Ruby implementers for almost two years. Every major Ruby implementation is using it. However, many Ruby programmers are just learning about it. RubySpec has a lot to contribute to the larger Ruby community. Recently, I explain some ideas about this in an interview with Gregory Brown. Greg is starting a project, called Unity, to make the information contained in the RubySpecs more accessible to everyone.

Contributing to RubySpec is a great way to learn more about the Ruby programming language. At the same time, your contribution helps the alternate Ruby implementations and the Ruby ecosystem. In the past couple of weeks, contributors have added tons of fixes to the specs for Ruby 1.8.7 and 1.9. Check out their excellent work at the RubySpec Github repository.

I'll be speaking about RubySpec at the upcoming Open Source Bridge conference June 17-19. If you have questions about RubySpec that you'd like me to address, please leave a comment.

When we think of user interface design, we probably think first of digital artifacts: the web applications, phones, or computer applications we use. But user interface design is much broader than that.

For example, I was at a workshop recently and after lunch I wanted to ensure my bottle made it into the correct recylce bin of one of those three-part glass, plastic, trash combo things.  Unfortunately, instead of just tossing my bottle into the well-labeled bin, I spent half a minute trying to discern from the contents which was the correct bin. There were recycling symbols and other markings but no clear labels.  Maybe they had worn off. Regardless, those three bins were an interface for depositing waste.

While I'd like people to think as broadly as possible about user interface design, this talk focused on some important aspects of traditional digital interface design. According to Ryan, user interface design and application programming are closely related and interdependent. From the perspective of a programmer or designer, the user interface is simply another layer in the application. But to the user, the user interface is the only thing they interact with so to them it IS the application.

Good application architecture emphasizes the importance of interfaces between components over the implementation details inside components. However, when beginning work on an application, Ryan suggests the most important element is to construct a model for the application that makes sense to the user and allows for its implementation. To understand the importance of this model, Ryan points to the book Domain Driven Design by Eric Evans.

One of the main tasks for a UI designer is to determine how the application is split up into screens. A screen is the unit of conversation for the designer. Within the screen, the designer should start from the "inside-out", focusing first on the most important thing that needs to be displayed and adding the surrounding information.

Ryan selected Edward Tufte's books, particularly The Visual Display of Quantitative Information, as one of the best sources for understanding the principles of visual design, selection and use of color, and proportions for visual elements.

Ryan emphasized the importance of one principle in particular: the least effective difference. Essentially, this means using the smallest visual effect that will distinguish elements. By adding or lessening contrast between visual elements, we create a hierarchy of information on the screen to show the user what they need to focus on to accomplish a task.

This is just the tip of the iceberg of UI design. Hopefully it will encourage you to investigate further. Everything has an interface and the better they are designed, the happier we'll all be.