まず、水曜（ロンドン）または木曜（レディング）での私のトークへの参加登録にはまだ余裕があります。 参加は無料ですし、私の本が無料で当たるチャンスもあります。（ロンドンの方が参加者が多くなるので、レディングに参加される方が確率が高いでしょう:-) ） どうぞお早めに こちらをクリックしてサインアップ してください。
また、Javaパフォーマンスチューニングの公開トレーニング講座についてもご案内します。 私たちの最初の講座は トロント、 ストックホルム、 そして フランクフルト で開催予定です。 これらの講座に関心のある方は 当方までご連 絡ください。 すでにご連絡をいただいている方は、恐れ入りますがもうしばらくお待ちください。 開催場所に関する重要な準備が終わり次第、すぐに折り返し連絡させていただきます。
最後に、ようやくあの J2EE アプリケーションパフォーマンス管理(APM)の記事 を書き上げました。 おもしろい記事になっています。 この記事を楽しみ、またここから知識を得ていただければと思います。 APM は今年のバズワード（もっと正確に言えばバズ略語ですが）の一つですので、ここでその概要をつかんでください。
今号のニュースレターでもいつもの記事、ニュースなどをご用意しています。 ニュースによると、-server と -client はバージョン6.0 からは過去の遺物となるかもしれません。 希望的には、これら二つのコンパイラチームが各々の長所を一つの超高速 JIT コンパイラにまとめあげたため、と思いたいところです。 （開発チームの人員削減のために一種類のコンパイラしかサポートできなくなった、という別の可能性もありますが） また、C++ 対 Java の性能に関する入念な分析が非常に良い内容だったので、 今月の質問 の回答にしてしまいました。
記事の方では、Java5.0（旧称1.5）に追加された監視・管理機能に関して、安定した情報提供が始まっているように見えます。 そしてみなさんご注意ください、最近になって（未確認ですが）JVMPI サポートが 6.0 で打ち切られると聞かされました。 今は JVMTI があるから、ということです。 JVMPI ベースの監視機能を実装されている方は、Sun に確認した方がよいでしょう。
加えて、いつものセクションもほぼそろっています。 Kirk のまとめ では Cray についての雑談と、すばらしいディスカッションについてまとめています。 Javva The Hutt は彼の最新の日記を寄稿してくれました。 そして マンガの新作 と 多数の新規パフォーマンス tips も簡潔にまとめてあります。
小紙の漫画家 "profiler" 氏のファンの皆さん、彼の他の作品は APLawrence でも見ることができます。
Java パフォーマンスチューニング関連ニュース
仮想メモリ管理は今や時代遅れの技術になりつつあるのでしょうか？ これは興味深い質問であり、VM をメモリ内に固定するチューニングパラメタを探している人物から間接的に問いかけられたものです。 これはまた、Jack と私とで議論になった疑問でもあります。 この手の疑問が沸く理由としては、ページングと仮想メモリはアプリケーションを実メモリのあちこちにばらまいてしまうということがあります。 このことは、ほとんどの処理にとっては、OS とハードウェアが変換テーブルを用いて仮想メモリのアドレス解決をサポートしてくれるので現実的な問題とはなりません。 変換テーブルのおかげでものごとはあるべきところにあるように見えます。 では、OS とハードウェアが仮想メモリをうまく取り扱ってくれるのなら、なぜ私達はそれを使うのをやめることを提案しようとしているのでしょうか?
理由の一つは、私達は Java 仮想マシンという伝統的な C/C++ アプリケーションとは違ったメモリの利用の仕方をする特定の種類のプロセスを走らせている、ということです。
Cray スーパーコンピュータを見て最初に驚いたことの一つは、 BSD UNIX (UniCOS) を走らせているにも関わらず、 OS もハードウェアも仮想メモリをサポートしていないことです。 このことが意味するのは、クレイ上で動くすべてのプログラムのすべてのビットはいかなる時も実メモリ上にあるということです。 なぜこんな事をするのでしょう？ その理由はごく単純であることが分かりました； ディスクに対するページのスワッピングはハードウェアのサポートによるベクトル処理の利点を台無しにしてしまうのです。 ベクトル処理のハードウェア/メモリバンクはどのクロック単位においても単一の結果を生み出すように高度に最適化されています。 メモリのアドレスをマシン上の異なるメモリバンクに散らばらせることによってそれを実現しています。 もしも OS/ハードウェアが、そのアドレスがメモリ上にあるのかないのかを知るために計算をしなければならないのなら、ベクトルプロセッサの利点が損なわれるでしょう。 つまり、メモリスワップに掛けられるようなコストは無い、ということです。
クレイ研究所はかつてプログラムの実行に関する研究を行いました。 その研究によって、プログラムの実行は大いに局所化されており、その場所はゆっくりとプログラム内を移動していくということがわかりました。 この情報は命令バッファ (実行されるべき命令が次の 40ワード に渡ってキャッシュされる) を最適に構築するために使われました。 この最適化の目的は、次の命令を得るために RAM にアクセスしなくても実行できるようにすることでした。 こういったケースでは、RAM へのアクセスがアプリケーションの性能に悪影響を及ぼすということがわかったのです。 この最適化では仮想メモリには何もしていませんが、ここで言えることは、クレイ研究所は RAM へのアクセスでさえコストとしては十分であり避けるだけの価値はあるということ を発見した、ということです。 さて、RAM から CPU への移動のコストに加えてさらにディスクから RAM への移動のコストがかかることを考慮するなら、共有テキスト (メモリイメージに有るプログラムの命令やシンボルの一部分) がディスク上にスワップされることを何故望まないかが理解できます。 UniCOS は Unix によく似たものに見えますが、被り物の下は全く別の生き物なのです。 クレイは彼らの顧客のアプリケーションを理解しその知識をハードウェアの設計に活かすことで驚くべき実行速度を達成できました。
多くの点で、Java 仮想マシンの実行プロファイルはクレイ上で実行される任意のアプリケーションと比べると予測し易いものです。 メモリ管理を例に取ります。JVM は Java ヒープスペース (非常に大きな C ヒープの塊)を持っており、オブジェクトのデータスペースを作るのに使います。 オブジェクトが参照されなくなったときに再利用できるようにメモリを取り戻すのは JVM の仕事です。 さて、性能問題が忍びよってくるのはこの部分です。 別のオブジェクトを参照しているオブジェクトがメモリの同じページに配置されるとは限りません。 もし関連する2つのオブジェクトが同じページに無ければ、片方がメモリ上でもう一方がディスクにスワップされるということは十分有り得ます。 こういったオブジェクトをたどっていくと、メモリのどこか (仮想メモリは実メモリ上にあるかもしれないしないかもしれません) を指している参照を解決しようとして OS によるスワップイン/スワップアウトを引き起こすでしょう。 このシナリオでは、単純かつ素早くあるべきガーベジコレクタがかなりの時間を費やしてしまうことになりそうです。
「デッドタイム」を避けるためには JVM のいかなる部分もディスクにスワップアウトされないようにしなければなりません。 言い換えると、利用可能な実メモリの大きさを超えないように使用メモリの最大値 (-Xmx フラグで指定) を設定しなければなりません。 利用可能ということで言えば、他のプロセスによって消費されるメモリの大きさも考慮しなければなりません。 また、JVM 自身が消費するメモリの大きさも考慮する必要もあります。 これらの情報を考え合わせると、クレイの教えに従って仮想メモリをすべてオフにすることに意義が見出せます。 ガーベジコレクタはあなたに感謝することでしょう。
www.javagaming.org で "-XX:MaxGCPauseMillis=2" という指定のことを書いた投稿を見ました。 Sun は 1.5/5.0 のリリースにおいて GC を制御するためのさらなるオプションを徐々に露わにしつつあるようです。 全体的に GC は 1.5/5.0 リリースで大きく向上しているようです。 Jack と私は、これに練習問題をやらせる日のことを楽しみに待っています。
アプリケーションの実行中に CPU の種類を判定する手段が JVM に何か有るでしょうか? こうした質問をする動機は、実行時の情報を開発者が CPU の負荷を減らすことに使えないかという期待です。 提案が 3つ有りました。最初の回答; その CPU はあなたのプログラムを実行中です。 (訳注: フォーラムでの元の質問には「JVMに」という言葉が含まれておらず、そこに引っかけた茶々入れっぽい) 2つ目の回答は、その種の情報を取得するためには JNI を利用するという手段を選ぶ必要があるというものでした。 より興味深い回答は、フレームレートを使って (ゲーム) アプリケーションが付いて来られるかどうかで調査するというものでした。 このやり方は他の分野では使えないものでは有りますが最も重要な問題点を強調してくれます： あなたのアプリケーションは割り当てられた仕事を割り当てられた時間内に処理できていますか?
フォーラムでは時折、情報が詰まり過ぎていてコメントすることも要約することも難しいようなスレッドに出くわすことが有ります。 www.javagaming.org にこの種のスレッドが絶えないという事実が、最後の1ビットまで性能を絞り出そうとする才能と献身の存在を示しています。 このスレッドは、近ごろようやく落ち着いた (と願いたい) Java 対 C++ 論争を発端とするものでした。 議論の口火を切った投稿はマンデルブロ集合を計算するコードでした。 最初に得た結果は注目すべきもので、(AMD Athlon 上で) -client オプションを付けて実行したベンチマークの方が -server オプションを付けたものより結果が良かったというものでした。 フォーラムの他の人々が原因を調べようと試したところ、 その誰もが -server 付きで実行した方がパフォーマンスが良いという結果を得ました。 多少の議論の結果、元の結果は AMD Athlon 上で Sun の JVM を使って得られたものであるのに対して、期待どおりの結果が得られたのは Intel Pentium 4 上だったことがわかりました。 説明を求めて彼らは JIT 内部に「押し入り」、AMD プロセッサ向けの正しいネイティブコードを生成していないことを突き止めました。
この結果自体が興味深いものですが、解析はそれだけに留まりませんでした。 JIT が生成したコードと gcc が生成したコードとが比較され、その結果、コンパイラがそのプロセッサにとって最適なネイティブコードを生成しないために C のコードの方が遅いという結論に達しました。 この解析から得られた決定的な結論は、Java で書かれたプログラムはハードウェアに合わせて JIT が調整できるので良好な性能が得られるのに対して、C/C++ ではそれができない、というものでした。 しかし、これで終りではありません。更なる詳細を明らかにするためにスレッドは続きました。
どうやらサーバ JIT は Streaming SIMD Extensions (SSE2) に依存しているようです。 もしも使っているプロセッサがこの機能を持っていないのであれば -client オプションを使った方が良好なパフォーマンスを得られるでしょう。 ただし、こういうときはいつも、自分で実際に計測をして推測を裏付ける必要があります。 ところで、このスレッド は話題を変えて続いています。
私は時々、雇用者が特定のウェブサイトにアクセスすることを制限するようなサイトに巡り合います。 その制限のリストに www.javagaming.org が含まれていることはしょっちゅうです。 私に言えることは、それは本当に残念なことだということです。 なぜなら、開発者たちを www.javagaming.org に連れてくるものはゲームであるかもしれませんが、 このサイトをユニークなものにしているのは、ものごとがいかにして働いているのかを解明することへの彼らの愛情だからです。 彼らの良き仕事が続きますように！
Java データ型に関しての シュールなユーモア。 あるいは、こんなことを面白く感じてしまうのは俺のオタク性ゆえかもしれん。
この文章 は、.Net と Java の、とてもよい比較記事だ。 俺がこれを要約するならば、こんなところだろうか。 「Java は何年かぶん多くの努力が投入されているので、より安定して機能も多い、そしてクロスプラットフォームだ。.NET の背後にはマイクロソフトが居る。」 それ以外の点では、将来性はどちらも同じようなものだろう。 .NET は、彼らが有用と思ったものを Java からすべてコピーし、Java も .NET から有用なものや人気の高い機能をなんでもコピーしているのだから、これはさほど驚くことじゃあない。 それは、俺たち開発者にとっては素晴らしいことだ。 それは、マイクロソフトがここ数年間で初めて直面した真の競争だろう。 開発サイクルがものすごく加速したドットコムブームのときみたいな感じで、Java と .NET 両方が進化していくのを見られるんじゃないかと思う。 俺の考えでは、これまで俺たちが IT 業界で見てきたどんなものよりも進んだ形の、Java と .NET による複占が形成されつつあり、それはこれから 5〜10 年ぐらいは続くんだろうと思う。 君がもし、どちらかに関する製品やサービスを作ろうと考えているなら、今すぐやるべきだ。 君は、まさにカーブの立ち上がり地点にいるんだ。
3月5日
断るには良すぎる転職話がやってきたんで、ここで残念ながらジャヴァ・ザ・ハットの終わりを宣言しなきゃならないようだ。
これまで数年間書いてきたことや、俺の知ってるみんなについて書くことは、あとちょっとでおしまいになるだろう。
これまでを振り返ってみれば、かなりものになる：シンパシー、見当つかず、Boris,Brainshrii, Weevil, Frezian, Parsons, 細目, 大口, Hilite, Vlad, 双子のエージェントスミス：エージェントその1 とその2, 6ポイント, ローゼンクランツ N. ギルデスターン, ベルゼブブ。
ベルゼブブはただのコンピューターだから、リストに入れるべきじゃないんだろうが、俺はやつのことは擬人化して考えてるみたいだ。
んー、もしかしたら、新しい仕事でも書くことは続けるかもしれない、けど今のところは、どんな生活になるかもわからないし、なんとも言えないな。
3月19日
信じられん。
とても信じられんよ。
怒りの余り爆発しそうだ。ドドーン！！
よーく考える必要があるぞ。
復讐はよく冷やした状態が一番だ。
史上最強のバナナスプリット (訳註:バナナとアイスクリームで作ったデザート) 級の復讐をやるぞ。
準備は整った。
ともかく、Weevil は「我々が一番 Java をうまく使えるんだ株式会社」
からの実在の手紙を入手して、それをベースに完璧に素晴らしい引き抜きの手紙を作ったんだ。
俺は、あやうく会社に退職の告知をしそうな所だった。
先方の人事部に電話して、いくつかの気になった点を明らかにしようとしてはじめて、そんなオファーが実際にはなかった、ということに俺は気づかされたのさ。
信じられるか？
やつこそ、完全な、四つ星級の、むかつく野郎だよ。
これが俺のやるべきこと一覧だ：
じゃあまたな
すでに Java と他の言語のパフォーマンスを比較検討したことは何度もありますし、個人的にはかなり飽き飽きしています（C++ は Java なみに速い、というのが正解です）。 そう思っていたところに この件に関するすばらしい議論 を見つけたのですが、これはこの問いに再度目を向けて、今月の質問に取り上げるに値すると思いました。
The JavaPerformanceTuning.com team
http://www.JavaPerformanceTuning.com/articles/apm1a.shtml
アプリケーションパフォーマンス管理
(最終更新 2004/7, 追記 2004-07-26, 著者 Jack Shirazi, 出典 JavaPerformanceTuning.cm). Tips:
http://kirk.blog-city.com/read/675658.htm
臭いコード、それは X = null
(最終更新 2004-7, 追記 2004-07-26, 著者 Kirk Pepperdine, 出典 Blog-City). Tips:
http://www.javahispano.org/text.viewer.action?file=jack_en
Jack Shirazi へのインタビュー
(最終更新 2004-7, 追記 2004-07-26, 著者 Martin Perez, 出典 JavaHispano). Tips:
http://www.javaspecialists.co.za/archive/Issue090.html
Autoboxing のパフォーマンス
(最終更新 2004-6, 追記 2004-07-26, 著者 Heinz Kabutz, 出典 javaspecialists). Tips:
http://www.informit.com/articles/article.asp?p=174533
Java でのアスペクト指向プログラミング
(最終更新 2004-6, 追記 2004-07-26, 著者 Tim Stevens , 出典 informIT). Tips:
http://www.devx.com/Java/Article/21453
SWT への招待
(最終更新 2004-7, 追記 2004-07-26, 著者 Raghu Donepudi, 出典 devX). Tips:
http://java.sun.com/developer/community/chat/JavaLive/2004/jl0520.html
J2SE 1.5 モニタリングと管理 (part 1)
(最終更新日 2004年5月, 追記 2004年7月26日, 著者 Edward Ort , 発行者 Sun). Tips:
http://java.sun.com/developer/community/chat/JavaLive/2004/jl0608.html
J2SE 1.5 モニタリングと管理 (part 2)
(最終更新日 2004年6月, 追記 2004年7月26日, 著者 Edward Ort , 発行者 Sun). Tips: