全体のキャッシュミス率をここまで大きく変化させることは少ないであろう。しかし、L2キャッシュ ミス率の減少は、非常に僅かであっても無視できない性能向上につながる可能性がある。
6.9. 動的データ配置技術のJPEベンチマークによる評価 109
Session Bean
Entity Bean 3 . r eceiv eEv ent C ontr ollerJP EJP E
C ontr oller Ev ent
D istr ib u torEv ent
D istr ib u tor Ser v ice Scenar ioSer v ice
Scenar io D isp atch erD isp atch er
Relational D atab ase
Ser v ice Ser v ice Ser v ice Ser v ice Ser v ice Ser v ice
JD BC RM I
RM I 1 . enq u eEv ent
8 . enq u eEv ent
2 . r eceiv eEv ent
7 . send Ev ent 4 . ev ent EJB Local (Reflection) 6 . send
5 . ex ecu teQ u er y EJB Local
Ser v er JV M C lient JV M
図54: JPEベンチマーク
（4）Serviceビーンでは、セッションの生成時に128個のintの配列を4096個生成し、各イベント
（セッションごとに5イベント）において、各配列の先頭を10回ずつアクセスする。さらに、
Java処理系の関係データベース接続（Java database connectivity; JDBC）機能を使って、関 係データベースの行を直接アクセスする。返答が必要な場合は、与えられたServiceScenario オブジェクトを使って返答を送信する。
（5）ServiceScenarioオブジェクトは返答用の作業スレッドを起動し、返答用スレッドは EventDis-tributorクラスを用いてクライアントJavaVMに返答を送信する。
6.9.3 VTuneによる特性解析
JPEベンチマークの解析の一環として、Xeonプロセッサにおけるハードウェア性能モニタリン グイベントの計測を行なった。ハードウェア及びオペレーティングシステムの環境は、マイクロベ ンチマークの計測で使用したもの（表5）と同じである。但し、頻度別割当VMの代わりに、ノー マルなJavaVMを使用した。
表7に、JPEベンチマークを配備した環境を示す。
JPEベンチマークのイベント計測は、起動後1回上記設定で実行した後、続けて2回目に同一の 設定で実行したときに行った。従って、実行頻度の高いJavaメソッドは既にJITコンパイルされて おり、ベンチマークは定常状態にある。
表 7: VTuneでの性能解析時の実行環境
J2EE処理系 WebSphere Application Server Enterprise Edition Version 5.02 関係データベース Cloudscape Version 5.1（Embedded）
表 8: トレース時の実行環境
サーバ xSeries 360 4-way Xeon MP、内部周波数1.4GHz、外部周波数
400MHz、8KB L1 cache、256KB L2 cache、512KB L3 cache、
3GB memory, 36GB SCSI disk x1、70GB SCSI disk x2 オペレーティングシステム RedHat Linux 7.3
Javaアプリケーションサーバ WebSphere 5.02
データベース・プログラム Cloudscape 5.1（embedded）
トレース生成VM ベースJava VMバージョン：Java version “1.4.1”
JPEベンチマークの解析結果を示す。図55は、JITコンパイルによって生成されたコードの実行 時間の分類を示す。
図56はキャッシュミス率を分類したものである。
JITコンパイルされたコード全体のL2キャッシュミス率は17.3%である。これは、JPEベンチ マーク本体のコードのキャッシュミス率が21.3%と極めて高いためである。配列オブジェクトをア クセスする際に、キャッシュの容量の不足及びキャッシュラインの衝突によるキャッシュミスが頻発 しており、マイクロベンチマークにおいてキャッシュミス率が高い場合と同様の状況であると考え られる。
6.9.4 トレース情報の収集
JPEベンチマークについてオブジェクトへのアクセスのトレース情報を収集した。収集した情 報は、
• オブジェクト生成箇所（割当サイト）
• オブジェクト毎のアクセス回数
• アクセスした領域のサイズ 等である。
表8にトレースを取得した実行環境をまとめる。
6.9.5 ホット/コールド判定の閾値の分析
オブジェクト毎にアクセス回数がアクセス全体に占める割合を調べた。ある割合rを閾値として 与え、全アクセス回数*r回以上アクセスされたオブジェクトをホットオブジェクトと考えることに
6.9. 動的データ配置技術のJPEベンチマークによる評価 111
WebSphere (com /*) 1 5 . 8 %
Cloudscape (db2j/*) 1 0 . 2%
Java Utilities (java/*) 1 1 . 0 %
JP E (n tt/*) 6 1 . 4 %
O thers 1 . 7 %
図55: JITコンパイルコードの実行時間の分布
する。例えば、閾値rが0.1%で全アクセス回数が10,000回の場合、10回以上アクセスされたオブ ジェクトがホットオブジェクトになる。
この閾値を0%、0.05%、0.1%、0.2%、0.4%、0.6%、0.8%、1%と変えて、ホットオブジェクトの アクセスが全アクセスに占める割合を求めた。0%ではオブジェクトの全てがホットオブジェクトに なる。閾値が上がるに従い、より少数のホットオブジェクトが選ばれる。
図57は、横軸に閾値の変化をとり、縦軸にホットオブジェクトへのアクセスの割合およびホット オブジェクト数を示している。1番目の線（% of access）は、各閾値におけるホットオブジェクト へのアクセスがアクセス全体に占める割合を示す。2番目の線（# of objects）は、ホットオブジェ クトの個数を示す。閾値0%の場合に、# of objectsはオブジェクト全てを示し、オブジェクト全数 は1247個である。また閾値0%時の% of accessの100%に足りない部分はクラス変数へのアクセス である。
図57が示すように、34%のオブジェクトが77.2%のアクセスを（閾値0.05%）、16.0%のオブジェ
クトが62.4%のアクセスを（閾値0.1%）、8.3%のオブジェクトが49.6%のアクセスを（閾値0.2%）
占めている。このように、オブジェクトにはアクセス頻度の大きな偏り（ホットとコールドの温度
WebSphere
C l ou dsc apeJ av a U t il it ies
J P E O t hers
Tot al 0 %
5 % 1 0 % 1 5 % 2 0 % 2 5 % 3 0 %
miss ratio
L1 C ac he Load Misses L2 C ac he Load Misses DTLB Load Misses
図56: JITコンパイルコードのキャッシュミス率
差）があることが分かった。
6.9.6 オブジェクト中のアクセス領域の比率
オブジェクト中のアクセスされた領域（インスタンス変数または配列要素）の割合を調べた。１ つの受信スレッドのトレース情報において、アクセストレースから、オブジェクト毎にアクセスさ れた領域のメモリバイト数を求めた。次にそのオブジェクトに対応する割当トレースからオブジェ クトサイズを求めた。全オブジェクトについて平均すると、82.8%であった。
6.9.7 割当サイト毎のオブジェクトアクセス回数の分析
オブジェクト割当命令を実行している箇所（割当サイト）に関するオブジェクトアクセス回数の 偏りを調べた。割当サイト毎にそのサイトが割り当てたオブジェクトのアクセス回数を合計し、全 アクセス回数に対する割合を分析した。
図58は、横軸に割合の上位n割当サイト（全割当サイトは640個）、縦軸に全アクセス回数に占 める割合をプロットしたものである。図58中にプロットしている点はそれぞれ、上位n割当サイト の全アクセス回数に占める割合が5%、10%、20%、30%〜を超える割当サイト個数nとその全アク セス回数に占める割合を示している。例えば3番目の点である7、21.4の値は、上位7個の割当サイ トから割り当てられるオブジェクトへのアクセス回数の、全アクセス回数に占める割合が21.4%で あることを示す。
図58中、限られた割当サイトが割り当てたオブジェクトが、頻繁にアクセスされる傾向が観測で きる。全640個の割当サイトのうち、上位14個、61個、219個の割当サイトが割り当てるオブジェ