Ruby 1.8.6 (p368)およびRuby 1.8.7 (p160)の新たなパッチレベルがリリースされている(リンク)。Ruby 1.8.6-p368(リンク)およびRuby 1.8.7-p160(リンク)の変更については、Changelogsを参照のこと。これらはバグ修正リリースであるが、少なくとも1つの振る舞い上の変更が StringIO#ungetcの1.8.xアップデートに忍び込んだ(リンク)。それにより1.9.xと同様の振る舞いをする(詳細は投稿記事を参照)。
JRubyで、Charles Nutter氏がIKVM.NETでJRubyを実行する試みをおこなっている(リンク)。IKVM.NET(リンク)は、.NET(オープンソースMonoおよび Microsoftの.NETの両方)で実行するJavaの実装である。JRubyは、よく動作しているようである。たとえば、このGistは、IKVM のJRubyで実行するRailsを示している(リンク)。別のGistは、取るに足らないパフォーマンスのベンチマーク(リンク)を示している。IKVMのパフォーマンス は、SunのJVMおよびMRIの間に位置するものである(重要：これらはマイクロベンチマークの結果である)。
最後に、MacRubyチームは、0.5リリースに向けた実験的なブランチの作業を継続している。Laurent Sansonetti氏は、MacRubyメーリングリスト上で、更新状況を紹介している(リンク)。1つの変更は、ruby-ffi(参考記事)のサポートである。
RubyFFIコンパチブルなAPIは、現在開発中である。それは、新たなCディスパッチャー機能を使用する。現在、ポインター、構造(など他もあり)を 除くほとんどのタイプがサポートされている。このAPIについて素晴らしいことは、さまざまなRubyバージョンで実装されるので、MRI C拡張子をサポートする限り、それに基づいて既存のRubyライブラリを使用することができることである。
Ruby-ffiはRuby/DLに取って代わるものであり、JRuby、Rubinius、MRI 1.8.xおよび1.9(参考記事)でサポートされる。もう1つの速度の改善は、C/Objective-Cインタラクション向けのLLVMを使用することで実現でき る(同一のメールより)。
新たなC/Objective-Cディスパッチャーが記述されている。その考えは、libffiを使用する代わりにLLVMを使用しスタブをコンパイルす る。以前のlibffiベースの実装はもはや使用されず、C/Objective-C APIのほとんどを実行することができる。早期のベンチマークによると、新たなディスパッチャーは、トランクよりおよそ8倍高速であり、純粋な Objective-Cよりおよそ3倍遅いので、非常に,見込みがある。libffiの除去が目標であった。なぜならば、非常に遅いからである。
最後に、MagLevチームは以下のように言っている(リンク)。
Alphaユーザ向けアップロードされたMagLev 21583。RubyGemsはmaglev-ruby setup.rb --no-rdoc --no-ri; maglev-gemインストールレイクをインストールする。
RailsConfの出席者については、MagLevチームがMagLev BOF(リンク)を準備している。