MacRuby - Ruby 1.9のObjective-Cへの移植

作者 Werner Schuster , 翻訳者 James Neoman 投稿日 2008年3月10日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

パフォーマンス&スケーラビリティ ,

Ruby ,

プログラミング ,

スクリプティング

Apple社は、MacOS X上のRubyの改善を目的にした新しいプロジェクトを始めました。MacRuby(サイト・英語)プロジェクトは、Ruby1.9のObjective-C実行環境への移植です。

MacRubyプロジェクトのLaurent Sansonetti氏に、それがどのようなプロジェクトで、どのように進んでいるかについてインタビューしました。

 InfoQ: MacRubyプロジェクトは、Apple社の支援を受けていますか？

Laurent Sansonetti: MacRubyは、Apple社が始めたフリーソフトウェアプロジェクトです。今のところ、プロジェクトのメンバは、Apple社の社員です。しかしながら、我々は、もちろん外部の人たちの支援も欲しいと思っていますので、そのために、プロジェクトの開発をMacOSForgeでオープンにする事にしましたし、公開形式で進めています。

InfoQ:  MacRubyは、Ruby 1.9/YARVをベースにされたようですが、元のRuby1.9にどれくらい手を加える必要がありましたか？修正は、オブジェクトの生成方法をRubyのやり方から、Objective-Cのやり方にかえるのに必要なものがほとんどでしたか？ほかには何か修正の必要はありましたか？

Laurent Sansonetti: RubyのオブジェクトをObject-CのオブジェクトとしてC言語のレベルでキャストできるように、Rubyのオブジェクトのデータ構造を、Objective-Cのオブジェクトのデータ構造と整合性を持たせるように変更する必要がありました。

そのほかにも、オブジェクトアロケータをRubyのものから、Objective-Cのものを使うように変更しました。これによって、すべてのオブジェクトが、RubyのものもObjective-Cのものも、同じメモリプールから割り当てられるようになりました。

最後に、もともとのRubyガベージコレクタを取り除き、代わりにObjective-Cのガベージコレクタを使うようにしました。この変更は、簡単ではありませんでした。それは、ガベージコレクタは、デフォルトで世代別モードで動作すること、また、"write-barrier"の情報に基づいて若い世代のオブジェクトを回収するため、オブジェクトが格納領域に登録されるたびに、"write-barrier"が正しく設定されることを想定しているからです。

InfoQ: RubyのクラスにあたるObjective-Cのクラスの生成は、どのようにしているのでしょうか？実行時にすべてのクラスを動的に生成しているのですか？

Laurent Sansonetti: Objecttive-Cのクラスの生成は、Rubyのクラスが定義されると同時に行っています。また、MacRubyからObjective-Cのクラスがアクセスされた場合には、そのクラスは、実際に必要になった時点でYARVにインポートされます。

InfoQ:Rubyのオブジェクトからは、Objective-Cのメソッドは見えますか？

Laurent Sansonetti: もちろん見えます。その反対も同様です。RubyのメソッドもObjective-C側から見えるようになっています。

InfoQ: Rubyで議論になっているものにObjectSpaceがあります。JRuby1.1では、デフォルトでは使えないようになっていますが、Objective-Cでは、どのようしてにObjectSpaceの機能を性能上の問題が出ないように実現しているかご存じですか？

Laurent Sansonetti:  すべてのMacRubyオブジェクトは、同じメモリプールから割り当てられます。より正確には、単一のmalloc領域(詳しくは、/usr/include/malloc/malloc.hヘッダファイル参照のこと)からです。そのため、その領域を調べたり、その中にオブジェクトを生成するのは、大変容易です。この機能の実現には、労力は必要ありません。
しかしながら、手を加えていない元々のRubyに比べてMacRubyでのObjectSpace#each_object呼び出しは、かなり遅いことは覚えておいてください。MacRubyでは、要求されたオブジェクトだけではなく、フレームワークで作成されたObjective-Cの純オブジェクトを含むすべてのオブジェクトを返します。

$ ruby -ve "p ObjectSpace.each_object {}"
ruby 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0]
310

$ /usr/local/bin/ruby -ve "p ObjectSpace.each_object {}"
MacRuby version 0.1 (ruby 1.9.0 2008-02-18 revision 0)
 [i686-darwin9.2.0]
8759

$ /usr/local/bin/ruby -ve "framework 'cocoa'; p ObjectSpace.each_object {}"
MacRuby version 0.1 (ruby 1.9.0 2008-02-18 revision 0) [i686-darwin9.2.0]
48425

InfoQ: 互換性の点では、いかがでしょうか？Stringsは、NSStringsによるもののようですが、これに関して、互換性の問題はないでしょうか？ネイティブな拡張は、互換ですか？

Laurent Sansonetti: 現時点では、RubyのStringクラスは、NSStingを継承しており、String、NSStringの変換を高速に行います。従って、今のところ互換性の問題はありません。

しかしながら、非常に近い将来、Rubyの基本的なクラス(String、Array、Hash)に関しては、CoreFoundationの等価なもの(CFString、CFArray、CFDictionary)を使って実装し直すことを予定しています。これによって、機能を統一するとともに、双方のランタイムの間でコストをかけずに変換ができるようになります。内部的な経験から、典型的なアプリケーションでは、ランタイムを越えてやりとりが必要なオブジェクトは、ほとんどが基本的なものだとわかっているのもその理由です。

この変更が、もしかしたら、互換性上の問題を引き起こすかもしれませんが、Ruby 1.9とCの拡張部が互換性を保つよう最大限の努力をおこなうつもりです。

InfoQ: MacRubyの今後の計画はどのようになっていますか？

Laurent Sansonetti: MacRubyプロジェクトの最大の目的は、開発者の方々が、Rubyの環境下で非常に効率よく実行できるCocoaのアプリケーションを書けるようにすることです。それは、(今後もサポートは続ける予定ではありますが)Max
OS X Leopardで提供を開始したテクノロジーであるRubyCocoaでは不可能なことです。その目的を達成するためには、まだまだやることがあります。MacRubyが他のユースケースでもうまく動くようにしたいとも思っていますが、今回の変更や近い将来に予定している変更によって、そういったことも可能になるでしょう。マイルストーンの計画とファーストリリースを近日中に予定しておりますので、お見逃しのないよう。

MacRubyプロジェクトの状況確認をしたり、MacOSForgeでMacRubyのソースコード(source)をのぞいてみたりして下さい。Laurentのアナウンスは、ruby-coreリストのMacRubyや、キー付き引数の特殊な文法などのディスカッション(source)をご覧下さい。MacRubyがどう動くかについての詳しい情報に関しては、HowDoesMacRubyWork(source)wikiページをご覧下さい。

原文はこちらです：http://www.infoq.com/news/2008/03/macruby-objectivec

• 次へ >