Rubinius Roundup: SendSites, Info sources, Project management

Posted by Werner Schuster on Mar 31, 2008 08:22 PM

Community

Ruby

Topics

Runtimes,

Compilers,

Performance & Scalability,

Dynamic Languages,

Debugging

Tags

Virtual Machines,

Rubinius,

Debuggers

The best way to keep up with Rubinius is the IRC channel #rubinius, or the Log of the #rubinius IRC channel. While the IRC channel is a great source of information, there is a lot of chitchat to walk through. Two new blogs make it easier to keep up to date with the development.

The Unwinding the stack blog aims to provide an idea of the events with a new weekly newsletter about the Rubinius project. Michael Klishin, of this blog, also started the rubinius-book project on GitHub. Right now, this consists of a Table of Contents (which does provide a good overview over the wide range of topics in Rubinius).
Due to the nature of projects on Github, it's very easy to get involved with the project by forking of a new branch and working on a piece of the project. Since GitHub allows to keep track of the changes between the branches and allows for various kinds of merging between them, this permits everyone to get started and share the work from the start, with the later option of merging them back to the master branch.
 
The other new Rubinius blog is Building a Better Ruby, by Adam Gardiner, the developer behind the Full speed Rubinius debugger, already filled with two long articles on some basic constructs in Rubinius.

Another article by Adam explains Sendsites:

The Rubinius SendSite [..] is an object that is created for every send site (method call) in the Rubinius bytecode, and facilitates [..] optimisations.

To avoid confusion: a "send site" is the place in the code where a method is invoked  (in Smalltalk/Ruby parlance "message send"), i.e. something like foo.bar. As Adam explains in the article, the SendSites are necessary to allow for various optimizations to happen, among them concepts like (Polymorphic) Inline Caches, which cache the result of a method lookup, thus lowering the cost of virtual calls for many cases.

One side effect of the implementation of Sendsites is very useful, as Adam explains:

[A] SendSite contains a reference to a Selector object. A Selector is an object that represents a message (i.e. method) name. It consists of the symbol of a message, plus an array of links back to every SendSite that uses the same message. This can be extremely useful, as it provides the ability to locate all direct uses of a particular message (although indirect uses such as via send and the various evals are not caught).

This, together with the fact that the SendSite increments a counter every time it is used (i.e. a message send happened), allows to write very useful tools to analyze the loaded code and it's behavior and performance.
Most importantly: since all of this, Selectors and SendSites, are accessible from Ruby code, all this information can be accessed interactively from an irb shell or any loaded Ruby code. Considering that the Full speed Rubinius debugger is also written in Ruby using opcode replacement, Rubinius' design and transparency turns out to be a powerful platform to write instrumentation and montoring tools.

Finally, a video of Rubinius founder Evan Phoenix' MountainWest Ruby Conference 2008 talk is up - explaining how the Rubinius project is organized  and the experience with the "Free flowing commit bit" strategy, which lowers the barrier of entry for new developers - and why this is a good thing.

Check InfoQ's previous coverage of Rubinius.

• Older >