InfoQ

News

Common Ruby MVM API research kicked off

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

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

Watch Thread Reply

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.