Common Ruby MVM API research kicked off

Getting Ruby to exploit multiple CPU cores machines has been a problematic topic in the past. Ruby's interpreter has used userspace threading up until Ruby 1.8, which means the threads are scheduled by the Ruby interpreter. Ruby 1.9 changed this by switching to kernel threads - except that it uses a Python-like Global Interpreter Lock (GIL). While the GIL means that only one Ruby thread can run at a time, native code can run as many parallel threads as it wants.

JRuby, running on the JVM, has supported native threads for some time. One solution for exploiting multiple cores has been to run multiple Ruby processes, which can then be scheduled across cores by the OS. While JRuby threads can use multiple cores, applications like Rails - which aren't thread safe and thus must take up one JRuby process to themselves - let this become a popular solution for JRuby too.

Using multiple Ruby VMs has a host of deployment problems, like how to launch a new Ruby process, how to communicate with other processes, etc. The most obvious problem is launching a new Ruby process. It seems simple to do something like

system("ruby", file_to_run) 

to launch a new Ruby process. However: if, for instance, this code runs in JRuby, it can fail in many ways, e.g. if the only Ruby on the system is JRuby, which would have to be launched with "jruby". Other issues are the performance overhead: launching one or more JRuby's with the 'jruby" command would launch multiple JVMs. This is unnecessary since multiple JRuby instances can share the same JVM. However: to use that, JRuby specific code is needed to instantiate the new instance, which can vary across hosting frameworks such as BSF or the the one included in Java 6.

Rubinius, a Ruby implementation that currently also uses userspace threading, recently added MVM support. With this code

vm = Rubinius::VM.spawn "blah", "-e", "puts 'hello\n'" 

it's possible to launch a new VM. This solution does make use of multiple cores because every VM runs on it's own native thread. This means, all the VMs live in the same OS address space and run in parallel. The VMs, however, can't share any references or - actually - anything; the only communication is via a Rubinius-specific message passing API.

The issue with all these different solutions: writing code that wants to use multiple VMs is impractical across Ruby implementations, since every Ruby implementation needs to be handled very differently. A program that, for instance, wants to use something like Skynet, a Ruby version of MapReduce, using multiple VMs to run tasks in parallel,  will have to be adapted for every Ruby implementation.

This may be solved by a newly announced research project at the University of Tokyo, together with the JRuby team and Sun, aims to find a solution that will work across all Ruby implementation. From the press release:

A group led by Professor Ikuo Takeuchi at the Graduate School of Information Science and Technology, the University of Tokyo will collaborate with Sun's Tim Bray (Director of Web Technologies) and the members of the JRuby team to implement a multiple virtual machine (MVM) environment on both Ruby and JRuby. The MVM environment is expected to make Ruby programs run more efficiently than was previously possible. The results of the research are scheduled to be open sourced via the broader community of Ruby developers, which could inspire further innovations.

Previously, running more than one application simultaneously on Ruby required multiple interpreters, leading to excessive memory consumption. The proposed MVM environment could generate multiple VM instances on a single interpreter, allowing applications to run more efficiently. The collaborative research aims to clarify such technical issues as the definition of common interfaces for using MVM, parallelization of VM instances and memory sharing, and then to implement technologies that can be used on Ruby and JRuby. While Ruby has already been widely in use in commercial and other environments, the research on MVM will further enhance the performance and utility of Ruby.

In short, the expected outcome is a common API that will allow to launch and use multiple Ruby VMs. With a common API, every Ruby implementation can have backends that  ensure to offer the most efficient implementation. Eg. on Rubinius and JRuby, the VMs can share the same address space; for a legacy older Ruby version, multiple processes could be launched.
Another important aspect for the API is to define how the VMs can communicate. Rubinius message passing solution is one idea to use, simply because systems like Erlang use it to avoid many problems of shared memory. A similar solution was used in the JSR-121 Application Isolation API.