JRubyの起動時間についてのヒント

原文: チャールズ＝オリバー＝ナター

JRubyはRuby言語の実装の中では一際起動が遅い事で悪名高くなってしまいました。一部は、JITの生成品がなくてブートストラップして動き出すまでに時間がかかってしまうJVMを使っているせいです。起動の際のボトルネックが報告されて原因が解明されればそれを除く努力を我々はしていますが、JRuby自体にも問題があります。起動の問題は、実は簡単な設定問題である事もしばしばです。JRubyの起動を早くするコツを幾つか見ていきましょう。

注意。JRuby自体の起動は、他のJVM言語に較べると結構いい線いっていますが、MatzのRuby（一般的には最も速い実装とは言えない）の起動は素晴らしく早いです。

クライアント用のJVMを使う

これが何と言っても一番手っ取り早い方法です。OpenJDKとSunのJDKを動かしているJVMであるHotSpotには、「クライアント用」と「サーバ用」の二種類のバックエンドがあります。「クライアント用」はバイトコードをコンパイルする時、最適化は最小限に、始めのうちにササッとやってしまうだけです。一方、「サーバ用」は大規模にしかも全体的に最適化をする訳ですが、これが出来るようになる時点に到着するには長い時間が掛かりますし、最適化の為には多くのリソースが必要です。

JRubyとRails 3を仲良くさせる方法

原文 ニック＝シーガー

概要

jruby -S rails newapp -m http://jruby.org/rails3.rb

Rails 3のアプリを生成する際にはJRuby専用のテンプレート(-m http://jruby.org/rails3.rb)を使用して下さい。

RakeとAntを一緒に

原文: トム＝エネボ

JRuby 1.5リリースに含まれる新しいライブラリをレポジトリーに先日コミットしました。これについて述べる前にこの下にでている写真を見て色々と思いを巡らして下さい。そう！私たち皆の模範となるミスター・ポテトヘッドです。ミスター・ポテトヘッドは私たちを数時間に渡って楽しませる（少なくともおそらく楽しませてくれていたであろう）、柔軟なただのオモチャではなくて、澱粉質を多く含む食べ物でもあるのです。

ミスター・ポテトヘッド

(MyMollyPopさんの写真)

ちょっとトンチンカンな事を言っているな、と思う前にちょっと考えてみて下さい。実際のところ、私たちがプログラマとして日常やっているのは、ミスター・ポテトヘッドを造り上げているようなものではないですか。ソフトウェアを造り上げるという問題に私たちが直面した時、求められているのは、さまざまな部品をくっつけるだけではなく、部品を最も綺麗に組み合わせる事です。ソフトウェアデザインとは正しくジャガイモを飾り付けるようなものです。この記事の「ジャガイモ」はソフトウェアです。

大忙しの一週間。アンドロイド、Maven、Rake、C拡張、そして…

原文：　チャールズ＝オリバー＝ナター

（最後のブログ記事からどれ位経ったでしょうか?正解は「長い間」。カンファレンス続きで大忙しだった秋が終ったので、もっとブログを書くつもりです。これからは、一月に三つも会議に出かけないように忠告して下さい。）

やあ！この一週間はとても忙しかったです。でも、僕らは元気でせっせとコード書いてるって解るように、JRubyで何が起こってるかを見ていきましょう。

アンドロイド

今週の頭にJan Berkelの手伝いをやってRuboto IRBを最新のアンドロイド携帯環境で走らせる事に成功しました。細かい手直しが二つ三つ必要だったのと、Janが手伝うのに興味があるというので、この変更を追加して彼をRubotoのコミッタに追加しました。

Ruboto IRBのレポジトリはこちら→http://github.com/headius/ruboto-irb

最近、アンドロイド上で動くJRubyに対する私の興味が増してきました。極最近の事ですが、JRubyはJVMで動くメジャーな言語の内ではアンドロイド携帯で動いている間に新規のコードを作って動かす事が出来る凡そ唯一の言語なのだと思い至ったんです。GroovyやScalaやClojureでは双方向型のシェルを造るのは不可能。というのも、これらの言語はソースコードを一旦JVMのバイトコードにコンパイルする必要があって、JVMのバイトコードはDalvikのVMでは直接には動かないからです。

JRubyのJはJVMのJ

原文：トム＝エネボ

現在JRubyの開発に携わっている面々は皆Ruby、Java、そして勿論JRubyを熟知している情熱的なハッカーばかりです。とは言うものの、このプロジェクトの創成に関わった者は一人も居ません。JRubyの先駆者たちはそれがいいアイディアだったと考えたに違いありません—私もJRubyのことを初めて耳にした時そう思いました。ところが多くの人にとってはこれはそう自明の事では無いのかも知れません。そういう人たちは「JVMの上でJRuby書いていい事なんかあるのですか」と訊きます。僕らJRubyチームはちょっとネジが外れてるか、狂気の天才なのか、それともJVMを使うのは至極実利的な決断なのでしょうか。

Javaは登場した当時、存在していたプログラム言語をちょっと良くしたような物でした。Javaはそこそこ簡単であり、かつ既によく使われていたCやC++を進化させたような物であるにも拘わらず、ハードウェアに中立なバイトコードを走らせる事の出来る仮想マシンでした。ガーベージコレクションがJavaには実装されていたので、メモリ管理やコアダンプに大して気を捕らわれなくなりましたし、加えて中々総括的なライブラリを持っていました。特に目新しい物は無かったのですが、既にあったアイディアを上手い具合に組合わせて使える物になっていたと言えるでしょう。

これは私見ですが、このように二つの異なる物をJavaと言う一つのブランドで売ろうとしたSunのマーケット戦略は長い目で見ると失敗でした。この戦略では、プログラム言語とランタイムが全く同一の物であるかのように同じ名前で呼ばれる事になっていたのです。この戦略は、ランタイム（それ自体で充分に利点の有ったJava仮想マシン）にとって非常に不公平な物でした。更に、JythonやJRubyの様にJVMを基にしたプログラム言語が、プログラム言語としてのJavaとの混乱を招く事無しにJVMの良さを説明する事が出来なくなるという結果にもなりました。

本稿ではJVMの良い点と悪い点について触れることにして、JVMの姿を読者が垣間見る事が出来ると良いと考えます。

本題に移る前にもう一言。本稿で扱うのはSunのJVMについて私の知っている事に限っています。Sun以外からもJVMはリリースされていますし、それぞれに良さが有ります。私が以下に挙げる点の多くはそうしたJVMにも当て嵌ると思われますが、私がそうしたJVMの詳細に暗い事は断っておきます。