2010年7月24日土曜日
JRubyのメモリを観察するには
原文: チャールズ=オリバー=ナター
Ruby言語の各実装において、どんなメモリ消費を解析するツールがあるのかが近頃ちょっとした話題になっています。 それもその筈、Rubyで書かれたアプリケーションの(不具合の調査は言うに及ばず)メモリ消費の具合を詳しく調べるのは容易い事ではありません。 JRubyを使わないのなら、そうです。
JRubyはJVM上で走るので、JVM向けに作られた何十ものツールの恩恵に授かる事が出来ます。 中にはJDKに同梱されているものを含め、メモリの調査、解析、レポートをするものもあります。 ヒープダンプが欲しければ、Hotspot系のJVM(SunまたはOpenJDK)に含まれるjmapやjhatが使えます。 もっと高度なツールが欲しければ、Eclipseを基にしたMemory Analysis Tool、 メモリ及びCPU性能解析ツールであるYourKit、 今ではHotspotに含まれているJavaVMを始め、 数多くの選択肢があります。 こうした数多くのツールのお陰でメモリの調査には事欠きません。
本稿では実際にこのうちの二つのツールをどの様に使いこなすか見ていく事にします。 取り上げたツールは起動中のJVMを観察するグラフィカルなツールであるVisualVMと、 ヒープをダンプして事後解析を可能にするjmapとjhatのタッグチームです。
2010年6月15日火曜日
2009年12月1日火曜日
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の詳細に暗い事は断っておきます。
現在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の詳細に暗い事は断っておきます。
登録:
コメント (Atom)