Rubyバイナリを実行する必要なく複数のRubyインスタンスを発信することがいくつかの形で有効になった。JRubyはひとつのプロセスにおいて複数 のJRubyインスタンスを、それぞれを自身のネイティブスレッドで動作させたまま所有するのを可能にする(source)。MRIにおいて、なぜ「the lucky stiff（幸運な死体）」が同じことをするように、Sandbox Hackを提供する(source)のだろうか？
最近Rubiniusは下記のように使用が可能な、マルチプルRubyランタイムを発信するための適切なサポートを得た(source)。
Multi-VMの背景のアイディアに関して尋ねられたEvan氏は下記のように述べた。
もう一つの興味深いトピックはどのようにVMのコミュニケートを可能にさせるかということである。
原文はこちらです：http://www.infoq.com/news/2008/01/rubinius-multi-vm
最近Rubiniusは下記のように使用が可能な、マルチプルRubyランタイムを発信するための適切なサポートを得た(source)。
vm = Rubinius::VM.spawn "blah", "-e", "puts 'hello\n'"この意味合いを理解するため私達はRubiniusプロジェクト(サイト・英語)のEvan Phoenix氏(ブログ・英語)に尋ねた。
vm.join
p vm.stdout.gets
Multi-VMの背景のアイディアに関して尋ねられたEvan氏は下記のように述べた。
私はいつもあれこれの形態において、この種の機能があったことが分かっていました。将来のプランは複雑なものであるのです。そうです。それは新たなVMに作業させるのを遥かに簡単にするのです。本当の疑問はその作業が何でありどのようにそれが実行されるかということなのです。Evan氏はいくつかの実装の詳細を引き続き述べた。
現在それぞれのVMはそれ自身のネイティブスレッド（unix上のpthread）内で始められます。これはそれぞれのVMが他のVMの知識無しに動作するのを可能にし、スケジューリングをVM内で全く同じに保ちます。最後の発言は他の全てのMulti VMソリューションにも当てはまる。-System.exit()のようなグローバル、静的なメソッドを呼ぶかもしくはJVMをクラッシュするJNIコー ドを使用しているJRubyインスタンスは他のJRubyインスタンスも同様にだめにする。
Rubiniusはその中で大変優れたCプログラムなのでグローバルも何も要さず、またその複数のコピーが同じアドレススペース内で円満に混ざり合うのを許容します。
それらは一つのネイティブスレッドごとに一つを動作しているのでその一つでプロセス全体をクラッシュさせだめにする可能性があるのです。
もう一つの興味深いトピックはどのようにVMのコミュニケートを可能にさせるかということである。
パイプは一方通行で、そうですスタジオはサブVM用にパイプにリダイレクトされます。また私はとてもシンプルな共有メッセージパスシステムも追加しまし た。ひとつのVMはシングルでトップレベルのメカニズムを使用してメッセージを相手に送ることができるのです。このメカニズムは一つのVMが互いに相互作用するただ一つの場所なのです。またそれはメッセージを共有ストレージに並列するので、VM間におけるポインタ共有は存在しないのです。メッセージがOSプロセス間で簡単にパスされるのを可能にする共有メモリを使用するため既存の共有メッセージパスメカニズムを拡張することが可能です。この機能はRubinius git(source)リポジトリにおいて現在有効である（Rubiniusリポジトリにアクセスするためのgit使用に関するInfoQの記事(記事)を参照して欲しい）。もしあなたがRubiniusソースを簡単に目を通したかったら、Rubinius gitリポジトリ用のWebインターフェース(source)もある。例えばこれが上記のメッセージパスシステムのためのコミットなのである(source)。
原文はこちらです：http://www.infoq.com/news/2008/01/rubinius-multi-vm