JBoss 5.0 のベータ版が出てきたので、とりあえず例によって i5/OS 上で稼動させてみました。
Java 5.0 で実行しましたが、今回は 64bit/32bit の両方の Java VM での実行です。
環境変数の指定一つだけで簡単に切り替えて実行できるのはやはり i5/OS ならではですが、問題判別の容易性や使用可能メモリー、もしくは消費メモリーなどの観点でいろいろ違いがあります。
まずは i5/OS 上の 64 bit ネイティブでの Java VM 上での稼動です。
以下のコマンドを実行後、QShell を実行します。
ADDENVVAR ENVVAR(JAVA_HOME) VALUE(‘/QIBM/ProdData/Java400/jdk15’)
QShell の画面で JBoss の bin ディレクトリから run.sh を実行します。
i5/OS (OS/400) V5R4 Power PC 上の Java VM であることが確認できます。
WRKACTJOB コマンドの実行画面でのオプション 12 か オプション 5/メニュー 20 で「スレッドの処理」画面を表示すると、スレッド毎の状況をリアルタイムで表示させることができます。(F5 キーを押した時点での最新)
現在実行中のものは "RUN" と「状況」に表示されており、並行処理をしているような場合には複数の "RUN" が存在します。
オプション 10 を選択することにより、各スレッド個別のプログラム (クラス) の実行状況 (呼び出しスタック) を見ることができます。
上の画面の続きで、オプション 10 「呼び出しスタックの表示」の例です。
前述したように F5 キーを押すと最新のスタック状況が表示されますので、リアルタイムにどのクラスのどんなメソッドが使われているかがわかります。
これってかなり凄いことなんですよ。i5/OS しか知らない人はわからないかもしれませんが
......
F21 キーを押すと、ビューが変わります。
ちなみに左側の J とか L とかの"タイプ"については、オンラインヘルプを見ると以下のように書いてあります。
呼び出しタイプの簡略エンコード，あるいは要求処理プログラムまたはプロシージャーのレベルの簡略エンコード。考えられる値とその意味は次の通りです。
- ブランク = 要求処理プログラムでない OPM または ILE 呼び出し。
- 0-999 = OPM または ILE 要求処理プログラム・レベル。
- ++++ = OPM または ILE 要求処理プログラム・レベルが 999 を超 えています。
- P = I5/OS PASE ユーザー・コード。
- P+ = I5/OS PASE ユーザー・コード。ただし，正確な再開点は不明確。 1 スタック項目について 2 行になります。
- L = ライセンス内部コード。
- K = I5/OS PASE カーネル・コード。
- K+ = I5/OS PASE カーネル・コード。ただし，正確な再開点は不明確。 1 スタック項目について 2 行になります。
- J = JAVA コード。
32 bit 版の IBM 製 Java VM 上で実行してみましょう。
以下のコマンドを実行後、Qshell を実行します。
ADDENVVAR ENVVAR(JAVA_HOME) VALUE(‘/QOpenSys/QIBM/ProdData/JavaVM/jdk50/32bit’)
JBoss の起動方法はまったく同じです。
"IBM J9 VM"という表示で、この JBoss が実行されている Java VM が i5/OS ネイティブではなく AIX と共通の Java VM であることがわかります。
IBM 製 Java VM でも、i5/OS ネイティブの Java VM と同様にして各スレッドの状況をリアルタイムに見ることができますが ......
i5/OS ネイティブの Java VM のように、リアルタイムに現在どんなクラスのどんなメソッドが使用されているかなどということはわかりません。
上の画面で "RUN" になっているスレッド "00000088" にオプション 10 を選択/実行した画面です。
左側の "P"は "PASE ユーザーコード"を示します。
要は PASE のライブラリーコードが実行されていることしかわかりません。
F21 キーを押すとこんなビューになります。
トラッカビリティという意味では i5/OS 64bit ネイティブ Java VM の方が圧倒的にいいのですが、IBM 製 J9 Java VM は今回たまたま 64bit ではなく 32bit である故にメモリーの使用量という観点からは効率がいい面があります。
アドレッシングに使用できるビットが倍になるため、アドレス可能空間という意味では 64bit の方が大きく、それはいいことなのですが、各オブジェクトをアドレスするためにも倍のアドレッシングが必要になります。もともと 32bit で稼動したらメモリー空間が足りなくてしょうがない、というようなアプリケーションは現時点ではそう多くはないのかもしれません。
i5/OS の場合、どっちの Java VM で実行するにしても (上の例で見たように)
環境変数の設定だけで切り替えることができます。
あまり難しく考えずに、双方で実行してみて具合のいい方を取ればいい、というのも現実的な考え方かもしれませんね。
ちなみに、消費メモリー/アドレス可能なフリー･メモリー、については、コンソールから表示させることができます。
こちらが 64bit i5/OS ネイティブの Java VM で実行した場合の表示で、
こちらが 32bit J9 Java VM で実行中の表示です。
|
|