まず、Java言語の性能向上に関する従来技術を大規模通信システムに適用した場合の課題提起に 対し、問題意識が正しいかどうかを簡易なベンチマークプログラムにより明らかにする。
そして、プログラム全域に渡り最適化を行う技術として、動的コード再配置技術および動的デー タ配置技術を提案し、その実現方法について説明する。
6.1.1 Java言語の必要性
ハードウェア非依存な仮想ハードウェア環境を提供するJava言語 [73]の利用は、コンピュータ 技術の進化に応じたハードウェア更改の際のソフトウェア移植コストを大幅に削減すると言われて いる[74–76]。
IDCの報告[74]によると、C++と比較して、複数プラットフォームへの移植の際は25%のコス ト削減、開発工程に限れば40%のコスト削減効果がある。さらに、製品サポートコストが年間10〜
20%減、コードメンテナンスコストが年間30%減と言われている。
『半導体の集積密度は、およそ18カ月で2倍になる』というムーアの法則がある [77]。これま でのところ、この経験則はマイクロプロセッサの性能にもおおむね適用でき、『マイクロプロセッサ の性能は、およそ18カ月で2倍になる』という状況が続いている。このようなコンピュータハード 技術の進化を考慮すると、ハードの乗り換えは頻繁に発生するものと考えられる。従って、マルチ プラットフォームに対する移植コストを抑えることができるJava言語は、これからますます重要性 を増していくと思われる。
一方、コンピュータプロセッサの高速化に伴い、プロセッサ内部と外部メモリとの速度差は拡大 する傾向にある（図 37）。従って、Java仮想マシン（JavaVM）の性能においても、キャッシュや TLB（Translation look-aside buffer）の利用効率が大きく影響する。筆者らは、キャッシュの効率 利用の観点にて、JavaVMの性能改善に取り組んできた。
6.1.2 Java言語の性能に対するこれまでのアプローチ
Java言語は、中間コードによるインタプリタ方式という実行形態をとることや、メモリ管理が自 動化されていることから、処理性能が課題とされてきた。
Javaプログラムの実行速度は、オンラインコンパイラ(JIT [55, 78, 79] ,HotSpot [80])、高速ガ ベージコレクション機構(ジェネレーショナルGC, 並列GC [81, 82])等の研究開発の進展により、
コンパイラ言語(C/C++等)で記述したプログラムよりやや劣る程度まで上がってきている。
Java言語の性能向上により、クライアントコンピュータのみならずサーバサイドのアプリケーショ ンプログラムにもJava言語が使われるようになってきた。特にWeb系のサーバではアプリケーショ ン記述言語の主流となりつつある。
6.2. 要求条件 81
BSB (Back Side Bus) F SB (F r o n t Side Bus)
L2 c a c h e C P U c o r e
L1 c a c h e
M M U T LB
ex ) BSB sp eed: 2 . 4 G H z 2 5 6 b it / 8 = 9 6 G B/ s F SB sp eed: 4 0 0 M H z 6 4 b it / 8 = 3 . 2 G B/ s
virtual address
p h y sic al address
M e m o r y
図 37: プロセッサのバス速度例.
に示す。別のクラスを順次呼び出して行くというクラスを多数用意し、呼出処理をシングルスレッ
ドで10,000,000回繰り返すものである。全クラスを均等に呼び出すことから、本ベンチマークプロ
グラムではクラス数は処理量に比例する。
本ベンチマークプログラムにおいて、クラス数が多い領域は、大規模通信システムの特性である、
「クラスやメソッド数が多く特定のメソッドに偏りがない」という状況を再現しているものと考える。
測定はSMPのLinuxマシン上で行った。これは、コールエージェントのような大規模リアルタ
イムにおいては、処理性能の観点からSMPマシンが使われることが多いためである。この簡易ベ ンチマークプログラムはシングルスレッドで実行されるため、SMPマシンにおいてはいずれか一つ のプロセッサに処理が割り当てられ、他の背景的な処理(daemon等)は別プロセッサで実行される 状況となる。結果的に、ベンチマークプログラムで1プロセッサをほぼ占有することができ、ノイ ズの少ないデータが得られた。なお、シングルプロセッサのマシン上で測定した場合でも、daemon
public class Class1 { public v o id m eth o d (int i) {
Class2 inst2 = new Class2 ();
..
.inst2 .m eth o d (i);
.. } . }
public class Class2 { public v o id m eth o d (int i) {
Class3 inst3 = new Class3 ();
..
.inst3 .m eth o d (i);
.. } . }
public class Class3 { public v o id m eth o d (int i) {
Class4 inst4 = new Class4();
..
.inst4.m eth o d (i);
.. } . }
Class#1
Class#2
Class#3
Class#N
public class ClassN { public v o id m eth o d (int i) {
Class4 inst4 = new Class4();
.. } . }
n u m b e r o f c lasse s
m e t h o d i n v o k i n g r e t u r n
図38: 簡易ベンチマークプログラム
6.2. 要求条件 83 等の処理負荷による測定値の揺らぎが発生するだけであり、傾向は変わらなかった。
測定環境を以下に示す。
• ハードウェア: Dell precision workstation 210, 600MHz, 2-way, 512MB
• OS: Debian GNU/Linux woody, 2.6.0-test4 SMP kernel
• JavaVM: IBM Java 2 version 1.3.1
• ループ回数: 10,000,000回
• 測定回数: クラス数を変えて5回ずつ測定し平均値を取る
測定結果を図39に示す。図39中のreal、sysはそれぞれ、プログラム走行時間、OS等の処理時 間である。sysの値が小さいため、グラフ中ではsysを100倍して表示している。
0 500 1000 1500 2000 2500 3000
0 50 100 150 200 250 300 350 400 450 500
processing time [msec]
number of classes
sys*100 real
図 39: Javaプログラムの実行時間
図39においてクラス数が100以下の領域を拡大したものを図40 に示す。図40中、sysの値は 100倍して表示している。
図39 ,図40において、クラス数100以下の領域では非線型に処理時間が延びており、さらにク ラス数が増えるとクラス数に比例した処理時間となっている。
0 50 100 150 200 250 300
0 20 40 60 80 100
processing time [msec]
number of classes
sys*100 real
図40: Javaプログラムの実行時間(クラス数の少ない領域)
6.3. 動的コード再配置技術 85