InfoQ

News

Common Ruby MVM API research kicked off

Posted by Werner Schuster on Feb 28, 2008 09:15 AM

Community
Java,
Ruby
Topics
Technology,
Runtimes,
Performance & Scalability,
JRuby
Tags
Virtual Machines,
Rubinius,
MVM,
Threading,
Concurrency,
Multi-threading,
JRuby,
Ruby1.9
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.

No comments

Reply

Exclusive Content

Rob Windsor on WCF with REST, JSON and RSS

WCF is not just for SOAP based services and can be used with popular protocols like RSS, REST and JSON. Join Rob Windsor as he introduces WCF 3.5 and its new native support for non-SOAP services.

Christophe Coenraets Discusses Flex 3, AIR, and BlazeDS

Christophe Coenraets discusses Flex 3, Flex Builder, AIR, BlazeDS, Adobe and open source, integrating Flex with existing applications, and integrating RIAs with search engines and browsers.

Debunking Common Refactoring Misconceptions

Danijel Arsenovski attempts to dispel some of the myths around refactoring and how it applies to .NET developers.

REST Eye for the SOA Guy

In this presentation, recorded at QCon San Francisco, CORBA guru Steve Vinoski explains REST from the view of someone who comes to SOA from a traditional, RPC-oriented background.

Choose Feature Teams over Component Teams for Agility

Feature teams are key to scaling agility for large teams. In an excerpt from "Scaling Lean and Agile Development," Larman & Vodde show how feature teams resolve traditional problems & raise new issues

Billy Newport explains Virtualization

Billy Newport talks about virtualization, eXtreme Transaction Processing (XTP) and WebSphere Virtual Enterprise. He discusses hardware, hypervisor, JVM, application and data virtualization.

Virtualization and Security

While virtualization provides many benefits, security can not be a forgotten concept in its application.

Introduction to Agile for Traditional Project Managers

This session is specifically aimed at traditionally trained project managers who are new to Agile, and who would like to be able to relate the PMI's best practices to their Agile equivalents.