Javaにおける明示的メモリ管理
23
0
0
全文
(2) 1694. Java における明示的メモリ管理. 実行は不定期に停止することになる．さらに，GC の実装方式として広く採用されている世. おいて New 領域中の Survivor 領域に移動される．その後数回の Minor GC では Survivor. 代別ガーベジコレクションでは，短時間で終了する Minor GC と，長時間の停止を要する. 領域中にとどまるが，ある回数の Minor GC を経ても，他からの参照が存在するため実行に. Major GC が発生するが，次にどちらの GC が発生するかを予見すること，発生したとし. 必要と判断されたオブジェクトは Tenured 領域に移動する．この Tenured 領域への移動を. てその所要時間を見積もることは困難である．. promotion と呼ぶ．ここで，ある時点でプログラムから参照可能なオブジェクトを live オ. 近年，Java システムがサーバ分野での業務プログラムの基盤として用いられるようになっ. ブジェクト，参照不能なオブジェクトを dead オブジェクトと呼ぶ．一般的に，生成された. てきたが，予期しない Major GC が発生すると，長時間にわたってシステム全体が無応答. オブジェクトのほとんどは，すぐに不要オブジェクト，すなわち dead オブジェクトとなる. となる点が問題視されることが多くなっている．たとえば，企業の経理などの金銭に関わる. ことが知られている．よって，Minor GC は，実行回数は多いものの，live となるオブジェ. 業務や電子商取引などを支える基幹システムなど，ミッションクリティカル性を要求するシ. クト数が少ないため，短時間で処理が終了する．一方，Major GC は，発生回数は少ないも. ステム上においては，このような長時間停止を許容することはできない．実行ハードウェア. のの，GC の過程でヒープメモリ内の全 live オブジェクトを探索する必要がある点，live オ. リソースの増大により Java ヒープメモリも増大する傾向にあるため，この停止時間はさら. ブジェクトとして扱うオブジェクト数が多い点などにより，一般に，Minor GC 時間の数十. に長くなる傾向にあり，その解決が急務となっている．. 倍の時間を要する．この Major GC は Tenured 領域の使用可能メモリ量の減少によって発. 本論文では，Java における Major GC による長時間停止を軽減するため，GC 対象外メ モリの確保・解放を明示的に指示可能な明示的メモリ管理 API を提案し，Java プログラム の動作には影響を与えない実行時安全性を確保しながら，プログラムのスループット性能を. 生するため，本領域に対するオブジェクトの移動頻度を抑えることができれば，Major GC 回数を軽減することが期待できる． そこで，本論文では，Explicit メモリと呼ぶ GC 対象外メモリ領域を導入し，これまで. 低下させることなく GC 対象外メモリを利用可能とするための実装について述べる．また，. Tenured 領域に配置されていたオブジェクトを，ユーザ指示によって Explicit メモリに配. 提案する明示管理メモリに対応した Java 仮想マシンを作成し，アプリケーションサーバを. 置することで，Major GC 回数の減少および GC 処理時間の軽減を実現する手法を提案す. 用いて評価した結果について述べる．. る．Tenured 領域に配置されるオブジェクトは，何度 Major GC を発生させても回収され. 2. 明示的管理メモリの導入と API. ないような長寿命オブジェクトと，New 領域に配置されている間は live オブジェクトだが，. 本章では，提案する明示管理メモリの導入の必要性と，本メモリを利用するための API. このうち，長寿命オブジェクトについては，何度 GC を行っても dead とならないため，こ. Tenured 領域に移動してから dead オブジェクトとなる中寿命オブジェクトに分けられる．. について述べる．なお，以後の説明で述べる Java 仮想マシンは Hotspot VM 2) （JDK5.0. れを GC 対象外メモリに配置すれば，Tenured 領域の使用量を削減することができ，Major. update 5）を対象としている．. GC に至る回数の減少および GC 処理時間の減少が期待できる．また，中寿命オブジェク. 2.1 明示的メモリ管理の導入. トに関しても，ユーザ指示によって GC 対象外メモリに配置し，生存区間終了後に一括削. Java 仮想マシンでは，ヒープメモリに対して世代別 GC 手法を採用している．本 GC 手法. 除すれば，長寿命オブジェクト同様の効果を期待することができる．なお，中寿命オブジェ. では，Java 仮想マシンがプログラムの実行を行う際に利用可能な Java ヒープメモリを新世. クトのようなオブジェクトが live であり続ける区間については，プログラムから静的に判. 代領域（New 領域）と旧世代領域（Tenured 領域）の 2 領域に分割する．それぞれの領域不. 断できる場合もあるが，判断できない場合は，メモリプロファイラなどにより Tenured 領. 足時に GC を行うことになるが，Hotspot VM では，New 領域不足時の GC（Minor GC）. 域に存在するオブジェクト情報を取得することで，オブジェクトの生存区間を得ることがで. アルゴリズムとして Copy GC 手法，Tenured 領域不足時の GC（Major GC）アルゴリズ. きる．図 1 に Explicit メモリを用いた場合のメモリ使用イメージを示す．図に示すように，. ムとして Mark Compact GC 手法を用いている．両 GC 手法とも，GC 実行時は Java プロ. Explicit メモリは，Java ヒープメモリとは別の領域として確保された GC 対象外メモリで. グラムの実行が完全に停止する stop-the-world 型の GC である．プログラムの実行の際に. あり，本領域にオブジェクトを配置することで，Tenured 領域へのオブジェクト生成を抑え. 生成されるオブジェクトは，まず New 領域中の Eden 領域に生成され，次の Minor GC に. ることができる．. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(3) 1695. Java における明示的メモリ管理. ブラリなどの内部で生成されるような場合は，ユーザはオブジェクトの生成部分を操作す ることはできない．よって，Explicit メモリ領域へのオブジェクト直接生成を行う場合，目 的のオブジェクトの生成過程で生成された他のオブジェクトもすべて Explicit メモリ内に 配置することになるが，これでは領域利用効率が大きく悪化する．本問題を解決するため，. 1 度 Java ヒープメモリ上にオブジェクトを生成し，GC を何度か経過させた後に Explicit メモリに移動させることによって，短時間で不要となるオブジェクトが Explicit メモリに 配置されないようにした．また，Java はマルチスレッド対応システムであるため，マルチ スレッドからのオブジェクト生成要求，すなわち領域確保要求は，排他制御を用いて安全に 処理を行う必要があるため，直接生成処理は非常に重い処理となっている．Explicit メモリ へのオブジェクト生成をすべて直接生成とした場合，排他制御オーバヘッドが非常に大きく なることが予想される． 直接生成を行う方法として，ExplicitMemory オブジェクトに対する newInstance，newAr図 1 Explicit メモリを用いた場合のメモリ使用イメージ Fig. 1 Memory image using Explicit memory.. ray メソッドを定義した．これらのメソッドは JavaSE における java.lang.Class クラスや java.lang.reflect.Constructor クラスの newInstance メソッドと同じように使用可能である． Java ヒープメモリ内のオブジェクトを Explicit メモリに移動させる方法としては，Java. 2.2 Explicit メモリの生成. プログラム上で指定された区間内で生成される全オブジェクトを移動候補とする方法と，オ. Java オブジェクトを配置する Explicit メモリ領域と，Java プログラムからその制御を行う. ブジェクトの参照関係に基づいて移動候補かどうかを判断する方法の 2 種類をサポートする．. ための ExplicitMemory オブジェクトを定義する．Explicit メモリ領域は ExplicitMemory. プログラムの可読性向上のため，区間指定によって移動候補オブジェクトを指定する Explicit. オブジェクトの生成時に暗黙的に生成されるものとした．本領域内へのオブジェクトの生成. メモリを ContextExplicitMemory（Context 型 Explicit メモリ），参照関係に基づいて移. によってメモリ不足になった際は，Java 仮想マシン内で自動的に拡張する．拡張方法とし. 動候補オブジェクトを判断する Explicit メモリを ReferenceExplicitMemory（Reference. て，領域不足になるたびに別領域を確保し内部的に同一の Explicit メモリと見なす方法を. 型 Explicit メモリ）と定義した．Context 型 Explicit メモリでは，区間指定用 API とし. 用いることにした．. て enter メソッドと exit メソッドを利用できる．enter/exit メソッドは，これらのメソッ. 2.3 Explicit メモリへの移動候補オブジェクトの指示. ドを実行するスレッドに対して，enter∼exit メソッド間で生成するオブジェクトの移動先. Explicit メモリ領域へのオブジェクト配置方法として，直接生成を行う方法と，Java ヒー. 情報を与えるためのメソッドである．なお，enter メソッドをネストして実行することも可. プメモリ内のオブジェクトを移動させる方法の 2 種類をサポートした．Explicit メモリに対. 能であり，その場合，内側で生成されたオブジェクトは，直前に実行された enter メソッド. する直接生成だけでなく，Java ヒープメモリからの移動をサポートしたのは，Explicit メ. の対象 Explicit メモリに対する移動候補となる．ただし，exit メソッドの実行対象となる. モリ内の不要オブジェクト数を極力減少させつつ，マルチスレッド対応のための排他制御. Explicit メモリは，そのスレッドが実行した直前の enter メソッドの対象 Explicit メモリ. オーバヘッドを削減するためである．Java におけるオブジェクトの生成過程では，参照関. と同一でなければならない．また，enter∼exit 間で生成されたオブジェクトは，この時点. 係をなす他のオブジェクトや，目的オブジェクト生成時にのみ必要なテンポラリオブジェク. では対象 Explicit メモリへの移動候補であり，本当に移動するかどうかは確定しておらず，. トなどを生成することが多い．テンポラリオブジェクトは暗黙的に生成されることが多く，. 実際の移動処理が行われる時点で，live オブジェクトであるならば移動する．. その生成を正確に把握するのは難しい．また，そのようなオブジェクトが Java クラスライ. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). Reference 型 Explicit メモリを用いた場合，本メモリに関連づけたオブジェクトから参照. c 2009 Information Processing Society of Japan .
(4) 1696. Java における明示的メモリ管理. 図 3 HashMap に登録するキーと値の生成と Explicit メモリへの移動指示 Fig. 3 Generation and movement of key and value objects for HashMap.. live と判定されたオブジェクトを Explicit メモリに移動させる．enter∼exit 区間外で生成 図 2 Explicit メモリ API の利用例とメモリイメージ Fig. 2 ExplicitMemory API image and memory image.. された白い丸で表されるオブジェクトは移動しない．. Context 型 Explicit メモリは，ユーザプログラム上の範囲に着目したオブジェクト移動 方法であるため，特定のオブジェクトに関連したオブジェクト群のみを移動させたいよう. 可能な Java ヒープメモリ内のオブジェクトが移動候補となる．本論文では，オブジェクト. な場合への対応が難しい．たとえば，java.util.HashMap のインスタンスとその内部クラス. を Reference 型 Explicit メモリに関連づける方法として，本領域内にオブジェクトを直接. （Entry）のインスタンス，登録するキーオブジェクトと値オブジェクトだけを Explicit メ. 生成する方法を用いた．なお，Hotspot VM における Java ヒープメモリの Permanent 領. モリに移動させたいような場合を考える．図 3 に示すように enter/exit メソッドを記述す. 域内のオブジェクトは移動候補外とした．Permanent 領域内オブジェクトを移動させない. れば実現できるように思われるが，図 3 (b) の記述では key と val を作成するために生成す. のは，Permanent 領域内にはクラスオブジェクトなど Java 仮想マシン内部で使用するデー. るテンポラリオブジェクトも移動候補となってしまうことが避けられない．GC による移動. タが格納されるため，Permanent 領域以外に配置することが困難であるからである．. までに dead オブジェクトとなれば移動しないが，必ず dead になるとは保証できないため，. オブジェクトを移動させる際は，オブジェクトの参照補正が必要となるため，動作中の. Explicit メモリの利用効率が悪化する原因となる．また，HashMap に登録するオブジェク. Java プログラムを完全に停止させる必要がある．そのため，オブジェクトを頻繁に移動さ. トを生成する箇所すべてに enter/exit メソッドを挿入する必要があるため，プログラム修. せるとプログラムの実行性能に大きな影響があると思われる．そこで，オブジェクトの移動. 正量が多くなるという問題もある．. は，もともとプログラムの停止をともなう GC 中とし，GC でのオブジェクトの移動処理の. このような場合は，Reference 型 Explicit メモリを用いると，Explicit メモリに移動させ. 一部を Explicit メモリへの移動処理とすることで，Explicit メモリへのオブジェクト移動. たいオブジェクトだけを移動させることができる．この HashMap の例では，図 4 の 2 行. オーバヘッドを隠蔽することにした．. 目に示すように，最初の HashMap のインスタンスを Reference 型 Explicit メモリに配置. 図 2 に Context 型 Explicit メモリを用いたプログラム例と，メモリ上のオブジェクトの. しておくだけでよいことになる．以後は，この HashMap インスタンスから参照可能なオブ. 移動イメージを示す．プログラムの右側はメモリイメージであり，それぞれ Java ヒープメ. ジェクトだけが自動的に Explicit メモリに移動する．また，生成したキーオブジェクトと. モリと Explicit メモリを表す．丸印はオブジェクトである．まず，Explicit メモリ生成前 （図中 0 行目）は Java ヒープメモリのみが存在し，いくつかのオブジェクト（図中，白い. 値オブジェクトを HashMap に add するだけで自動的に移動候補とすることができるため，. enter/exit メソッドの記述が必要な Context 型 Explicit メモリ使用時に対してプログラム. 丸）が生成されている．2 行目を実行すると Explicit メモリ領域が生成される．4 行目から. 修正量も減らすことができる．. 6 行目の enter∼exit 区間内では，オブジェクトが Java ヒープメモリ中に生成される（図. 2.4 Explicit メモリの削除. 中，黒い丸）のは同様だが，GC が発生すると，黒い丸で表すオブジェクトのうち，GC で. Explicit メモリを削除する API として，reclaim メソッドを定義した．本メソッドを実行. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(5) 1697. Java における明示的メモリ管理. の生成，すなわち，Context 型 Explicit メモリの場合は ContextExplicitMemory クラス のインスタンス，Reference 型 Explicit メモリの場合は ReferenceExplicitMemory クラス のインスタンスを生成する際に，Explicit メモリ領域本体を確保する．これを実現するた め，各 Explicit メモリ生成時のコンストラクタ処理において，JNI を用いて Hotspot VM 内の関数呼び出しを行い，その内部で領域確保を行っている．なお，Explicit メモリ領域本 体の確保・解放処理では，実装の容易さと信頼性確保の点から，C ライブラリの関数（確保 は mmap 系関数による reserve/commit，解放は free 関数）を用いている．Expilcit メモ リ領域として確保するサイズは，本論文で用いた Explicit メモリ対応 Hotspot VM では固 定サイズとした．. Java プログラムの実行が進み，Explicit メモリにオブジェクトが配置されていくと，確 図 4 Reference 型 Explicit メモリの利用例 Fig. 4 Program example for ReferenceExplicitMemory.. 保した領域サイズでは不足することが予想される．このような領域不足時は，別の領域を確 保し，元のメモリを含めて論理的に 1 つの Explicit メモリ領域と見なすことによって，自動 的に拡張されたように見えるように実装した．ここで確保する別領域の大きさは，配置しよ. することによって，対象 Explicit メモリが領域内のオブジェクトごと削除される．その際，. うとしているオブジェクトが少なくとも配置できる大きさとした．なお，Explicit メモリ領. 以後のプログラム実行に影響を与えないようにするため，削除対象 Explicit メモリ内オブ. 域を際限なく拡張可能としておくと，OS や他のプロセスが用いる領域が不足しシステム全. ジェクトのうち，live である可能性があるオブジェクトは削除対象外メモリに移動させる．. 体が不安定になることが考えられるため，Java 仮想マシンの起動時オプションで Explicit. すなわち，削除対象外メモリから削除対象メモリへの参照がある場合は，参照先のオブジェ. メモリとして利用可能な最大サイズを指定するようにした．. クトを削除対象外メモリに移動させる．本論文では，Explicit メモリ領域削除時の live で ある可能性があるオブジェクトの移動先として，Java ヒープメモリを用いている．. 3.2 区間指定型 API によるオブジェクト移動 本節では，Explicit メモリへの移動候補オブジェクトの指定に，区間指定 API である. 3. Explicit メモリの Java 仮想マシンへの実装. enter，exit メソッドを用いた場合のオブジェクトの移動処理について述べる．. 本章では，2 章で述べた明示的メモリ管理 API を実現するため，Explicit メモリの生成，. する必要がある．その基本方針として，移動先管理配列という補助構造を Explicit メモリ. まず，指定区間内で生成したオブジェクトがどの Explicit メモリへの移動候補かを管理. Explicit メモリへの移動候補オブジェクトを実際に移動させる部分および Explicit メモリの. ごとに用意し，この配列から参照可能なオブジェクトを，その Explicit メモリへの移動候. 削除部分の Hotspot VM への実装方法について述べる．なお，本論文では JDK5.0 update. 補とすることにした．ここで問題となるのは，移動先管理配列が保持するオブジェクトへ. 5 の Hotspot VM に対する実装を想定しているが，プログラム修正は Hotspot VM のアー. の参照数である．Hotspot VM では，オブジェクトは世代別 GC における New 領域内の. キテクチャ共通部分に対してのみ行っているため，他のバージョンの Java に対しても容易. Eden 領域に生成され，生成されたオブジェクトのほとんどは次回の GC までに dead とな り，残りの live となったオブジェクトは Survivor 領域に移動する．よって，生成したオブ. に適用可能と思われる．. 3.1 Explicit メモリの生成と領域拡張. ジェクトすべてを移動先管理配列から参照させた場合，直後の GC でその参照の多くが削. 本節では，Explicit メモリの生成処理および領域不足時の自動拡張処理の実現方法につい. 除されるため，移動先管理配列の利用効率の悪化と GC 処理時間の増大の原因となる．ま た，Java はマルチスレッド実行であることが前提であり，Explicit メモリごとに持つ移動. て述べる．. Explicit メモリの生成においては，Java プログラム上での Explicit メモリオブジェクト. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). 先管理配列への参照の代入には排他制御が必要となるため，オブジェクト生成ごとに参照を. c 2009 Information Processing Society of Japan .
(6) 1698. Java における明示的メモリ管理. 代入するとそのオーバヘッドが大きすぎる．そこで，1 度 GC を経過しても live であるオ ブジェクト，すなわち Survivor 領域に移動したオブジェクトを，その GC の最後で移動先 管理配列から参照させることにより，生成直後に dead となるオブジェクトへの参照を抑制 することにした．本解決方法により，Eden 領域に生成される移動候補オブジェクトの移動 先管理が行われなくなるが，これは Java スレッドが持つ Thread Local Allocation Buffer を拡張することで対応した．. Thread Local Allocation Buffer（以下，TLAB）は，マルチスレッド対応システムであ る Java におけるオブジェクト生成オーバヘッドを軽減するための仕組みである．マルチス レッド実行時にオブジェクト領域を確保する簡単な方法としては，利用可能領域の先頭を表 す情報の書き換えを排他的に行うことが考えられる．しかし，排他制御は非常に重い処理で あるため，Java では TLAB という Java プログラム実行スレッド（以下，Java スレッド） に固有の領域を Eden 領域内に確保し，各 TLAB に対してオブジェクト領域確保を行うこ とによって，極力排他制御を行わないようにしている．図 5 に Java スレッドと TLAB の 関係を示す．図 5 (a) は従来の Java スレッドと TLAB のイメージであり，各 Java スレッ ドは 1 つの TLAB のみを持つ．プログラムの実行にともない，TLAB 内の利用可能領域が 不足した場合は，新しい TLAB を生成する．この際，それまで TLAB であった領域は，図 中の「過去の TLAB」として示す部分となるが，各スレッドはこの情報は保持していない．. 図 5 TLAB の利用イメージ Fig. 5 Image of thread local allocation buffer.. Context 型 Explicit メモリ使用時は，TLAB と Context 型 Explicit メモリを関連づけ， 各 Java スレッドが Context 型 Explicit メモリ用の複数の TLAB を管理するよう拡張を. である．たとえば図 5 (b) 中 Explicit メモリ 1 用 TLAB は 3 つあるが，現在有効な TLAB. 行い，Context 型 Explicit メモリへの配置区間指示 API の実行時に，使用する TLAB を. 情報のみを保持していた場合，情報を保持されなかった TLAB 内のオブジェクトについて. 切り替えるようにした．enter∼exit メソッド間で生成されるオブジェクトは，Context 型. は，移動候補であるかどうかを判断することができない．なお，Context 型 Explicit メモ. Explicit メモリ用 TLAB 内に生成されることになり，その TLAB 内の全オブジェクトは. リ用の TLAB 生成および切替え処理は，Explicit メモリ利用のためのオーバヘッドとなる. Context 型 Explicit メモリへの移動候補と見なすことができる．なお，enter∼exit メソッ. が，その大きさは非常に小さく，Java プログラムの実行性能に影響を及ぼすものではない．. ド区間内で生成するオブジェクトの配置先が Eden 領域中の TLAB ではない領域となる場. 3.2.1 Minor GC での Context 型 Explicit メモリへのオブジェクト移動. 合があるが，この場合はそのオブジェクト生成直後に移動先管理配列から参照させるように. Minor GC での Context 型 Explicit メモリへの移動処理について述べる．Minor GC で. している．ただ，このようなオブジェクトの数は非常に少ないため，プログラムの実行性能. の Context 型 Explicit メモリへの移動処理の疑似コードを図 6 に示す．まず，1 行目に示. には影響は出ないと思われる．図 5 (b) に Context 型 Explicit メモリ使用時の TLAB とス. すように，従来の Minor GC 同様，GC ルートから参照可能なオブジェクト群からの参照先. レッドの関係を示す．Context 型 Explicit メモリ使用時は，GC 間で各 Java スレッドが実. を調査する．1 行目で Context 型 Explicit メモリ内オブジェクトを GC ルートと同列に扱. 行した区間指示 API が対象としている Context 型 Explicit メモリ用の TLAB をすべて保. うのは，GC 対象外メモリである Explicit メモリ領域内オブジェクトを live として扱う必要. 持する必要がある．現在の TLAB だけでなく，過去の TLAB 情報まで保持しなければなら. があるためである．現在調査対象としているオブジェクト obj からの参照先が New 領域内. ない理由は，TLAB 自身が，その内部オブジェクトがどのメモリへの移動候補かを表すため. であり，その参照先 ref obj が移動先管理配列から参照されているならば，図中 5∼8 行に. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(7) 1699. Java における明示的メモリ管理. 域内の Survivor 領域に移動する．その後，参照元 obj からの参照先を ref obj の移動先に 補正し，GC 処理高速化のための補助構造であるバリアセットの補正を行う．この一連の処 理をオブジェクトが 1 つも移動しなくなるまで繰り返す．. GC 処理終了後，図 6 の 28 行目以降に示すように，移動先管理配列のメンテナンスを行 う．先に述べたように，移動先管理配列は，Explicit メモリへの移動候補オブジェクトのう ち，Survivor 領域に移動したオブジェクトへの参照を保持する．つまり，この GC におい て，Eden 領域内の Explicit メモリ用 TLAB 内から Survivor 領域に移動したオブジェクト への参照を保持すればよいことになる．そこで，29∼31 行目に示すように全 Java スレッド が持つ Explicit メモリ用 TLAB が管理する領域内の全オブジェクトについて，32 行目に 示すようにそのオブジェクトが Survivor 領域に移動したかどうかを調べ，移動していた場 合はその移動先を移動先管理配列に代入する．Copy GC 処理では，GC で移動させた全オ ブジェクトの移動元には，移動先を示す情報（forwarding ポインタ）が記録されているた め，Survivor 領域に移動したかどうかは容易に調査可能である． なお，図 6 の 1 行目に示す obj としては，Minor GC 時の GC ルートに含まれる Java ヒープメモリの Tenured 領域，Permanent 領域に加え，Context 型 Explicit メモリの各領 域にあるオブジェクトが該当する．これらの領域のオブジェクトすべてが New 領域への参 照を持つわけではないため，実際に全オブジェクトを調べるのは無駄である．Hotspot VM では，Tenured 領域と Permanent 領域から New 領域への参照有無調査を高速化するため， カードマーキング処理3) を行っている．カードマーキングとは，GC 処理時間の軽減のため のライトバリアの一種である．Hotspot VM には，Java ヒープメモリ領域を 512 bytes ご との領域に分割した際の，分割された 1 領域を 1 カードとして定義するバリアセットという 図 6 Context 型 Explicit メモリへの GC による移動処理のアルゴリズム Fig. 6 Algorithm of object movement to ContextExplicitMemory by Minor GC.. データ構造が存在する．Java プログラムの実行において，Java オブジェクトの参照フィー ルドに変更を加える，すなわち参照をストアする際に，バリアセット中の当該 Java オブジェ クトが属するカードに印をつけるライトバリアを行う．この処理によって，オブジェクトの. 示す Explicit メモリへの移動処理に進む．移動処理では，移動先の Explicit メモリを特定. 参照フィールドに変化があった可能性がある領域を特定できるため，Tenured/Permanent. し，当該 Explicit メモリに領域を確保し，実際に移動させる．また，ref obj が移動先管理. 領域の全オブジェクトを調査する必要がなく，処理時間を軽減することができる．Explicit. 配列から参照されていない場合は，図 6 の 12，13 行目に示すように，ref obj が Tenured. メモリから New 領域への参照調査を軽減するため，このバリアセットを Explicit メモリ. 領域への promotion 対象であり，かつ Explicit メモリ用 TLAB にある場合は，14 行目の. に対しても導入することにした．Explicit メモリ領域の配置は C ライブラリのメモリ管理. Explicit メモリへの移動処理に入る．すなわち，Eden 領域から，Survivor 領域への移動を. 部に依存しているため，メモリ中のどの部分に生成されるかは実際に生成するまで不明で. 経ずに Tenured 領域に移動するような場合は，TLAB の情報をもって，その移動先を決め. ある．よって，利用可能なメモリ空間全域をバリアセットでカバーすることにした．なお，. るということである．これ以外の場合は普通の Copy GC と同様であり，ref obj は New 領. Java プログラム実行時のカードマーキング処理は従来と同様であるため，プログラムの実. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(8) 1700. Java における明示的メモリ管理. 行性能に対する影響はない．. 3.2.2 Major GC での Context 型 Explicit メモリへのオブジェクト移動 次に，Major GC での Context 型 Explicit メモリへのオブジェクト移動処理について述 べる．通常の Major GC で用いる Mark Compact GC 手法は，オブジェクトの生死判定 （marking），Compaction による移動先計算，オブジェクトの参照補正，Compaction から 構成されるが，Major GC における Context 型 Explicit メモリへの移動は最初の marking 処理で行うことにした．移動対象オブジェクトの識別方法は Minor GC と同様である．そ の際，移動候補であるオブジェクトが live であればすべて移動させる点が Minor GC と異 なる． また，Context 型 Explicit メモリ内オブジェクトを，marking 処理におけるオブジェク トの生死判定の対象としている点も異なる．ただし，Context 型 Explicit メモリ内でのオ ブジェクトの compaction は行わず，dead オブジェクトを他への参照を持たないオブジェ. 図 7 Minor GC における Reference 型 Explicit メモリへの移動アルゴリズム Fig. 7 Algorithm of object movement to ReferenceExplicitMemory by Minor GC.. クトに変換するだけである．本処理により，Explicit メモリの削除時の処理時間の短縮およ び削除対象外メモリへのオブジェクトの移動量を減少させることができる．2.4 節で述べた ように，Explicit メモリ削除時は，削除処理後の実行結果を保証するため，削除対象メモリ. 移動処理は図中 1∼16 行目に示すように，通常の Minor GC 処理（18 行目）の前に実施. 内で live である可能性があるオブジェクト，すなわち削除対象外メモリから参照可能なオブ. することによって，Reference 型 Explicit メモリへのオブジェクト移動を優先的に行う．ま. ジェクトを，削除対象外メモリに移動させる．もし，削除対象外メモリのオブジェクトが本. ず，1∼4 行目に示すように，全 Reference 型 Explicit メモリ内のオブジェクトからの参照. 当は dead オブジェクトである場合，このオブジェクトからの参照調査や，その参照による. 先について，New 領域内オブジェクトであるかどうかを調べる．参照先オブジェクトが New. オブジェクトの移動処理は，Java プログラムの実行にとって無意味な処理となる．そこで，. 領域内にある場合，そのオブジェクトを Reference 型 Explicit メモリに移動させる．ただ. dead と判定できたオブジェクトを他への参照を持たないようにすることで，Explicit メモ. し，すべての Minor GC で移動させるのではなく，5 行目に示すように，その GC におい. リ削除の処理時間を短縮させつつ，削除対象外メモリへのオブジェクト移動量も減少させて. て Tenured 領域への promotion 対象である場合のみとすることで，ある程度寿命が長いオ. いる．. ブジェクトを移動させるようにした．これにより，Explicit メモリ利用効率の向上が期待で. 3.3 参照関係に基づくオブジェクト移動. きる．. 本節では，Reference 型 Explicit メモリにオブジェクトを移動させる方法について述べ. 図 8 に，Minor GC における Reference 型 Explicit メモリへのオブジェクト移動イメージ. る．前述のように，Explicit メモリへの移動は GC 時に行われるが，世代別 GC での Minor. を示す．図中，New は New 領域，Tenured は Tenured 領域，ReferenceEM は Reference. GC と Major GC のアルゴリズムに合わせて移動候補となるオブジェクトが異なる．. 型 Explicit メモリ，アルファベットを内包する丸印はオブジェクトであり，オブジェクト. 3.3.1 Minor GC における Reference 型 Explicit メモリへのオブジェクト移動. 間の矢印は参照関係を表す．図 8 (a) は初期状態を示しており，オブジェクト A と B は. Minor GC においては，Reference 型 Explicit メモリから参照可能な New 領域内オブ. Reference 型 Explicit メモリに生成済みである．また，オブジェクト C と D は Java ヒー. ジェクトを移動候補としている．図 7 に，Minor GC における Reference 型 Explicit メモ. プ領域における Tenured 領域に，オブジェクト E，F，G，H は New 領域内に存在するも. リへのオブジェクト移動アルゴリズムを示す．通常の Minor GC 処理中にオブジェクトを. のとする．なお，オブジェクト E，F は次の Minor GC で Tenured 領域に promotion する. 移動させる Context 型 Explicit メモリの処理と異なり，Reference 型 Explicit メモリへの. と仮定する．ここで Minor GC が発生すると，まずオブジェクト A と B からの参照を調. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(9) 1701. Java における明示的メモリ管理. Reference 型 Explicit メモリには移動しない． 3.3.2 Major GC における Reference 型 Explicit メモリへのオブジェクト移動 Major GC では，Reference 型 Explicit メモリから参照可能な New/Tenured 領域内オ ブジェクトを Reference 型 Explicit メモリに移動させる．Major GC における Context 型. Explicit メモリへのオブジェクト移動処理同様，Reference 型 Explicit メモリへの移動処理 は最初の marking 処理中に行う．Marking 処理でたどられたオブジェクトには処理済みで あることを示す印がつけられ（marking），mark 済みオブジェクトが 2 回以上処理される ことはない．そのため，Reference 型 Explicit メモリ内オブジェクトから処理を開始するこ とによって，Reference 型 Explicit メモリへの移動処理を優先的に行っている． なお，Permanent 領域内のオブジェクトや移動対象ではない他の Explicit メモリ内オブ ジェクトおよびこれらのオブジェクトを介して間接参照可能な New，Tenured 領域内オブジェ クトは移動対象外である．他の Explicit メモリ内のオブジェクトを Reference 型 Explicit メモリに移動させると，異なる目的のメモリにオブジェクトが移動することになるためであ り，Permanent 領域内オブジェクトを移動させないのは 2.3 節に示したとおりである． Fig. 8. 図 8 Minor GC における Reference 型 Explicit メモリへの移動 Image of object movement to ReferenceExplicitMemory by Minor GC.. 図 9 に，Major GC における Reference 型 Explicit メモリへのオブジェクト移動アルゴ リズムを示す．まず，1∼4 行目に示すように全 Reference 型 Explicit メモリ内のオブジェク ト obj を対象として marking 処理を行い，obj 自身をスタック oop stack に push する．6∼. べる．オブジェクト A からの参照調査において，New 領域内のオブジェクト E が直接参照. 21 行に示す while 文は oop stack にオブジェクトが push されている限りループするように. 可能であることが分かる．オブジェクト E は Tenured 領域への promotion 対象であるた. なっており，調査対象オブジェクトのすべての参照を追うことが可能となっている．このルー. め，ReferenceExplicitMemory に移動させる．オブジェクト A から参照可能なオブジェク. プ内では，7∼8 行の処理において oop stack から pop したオブジェクトの参照先を調べ，. ト C と，オブジェクト B から参照可能なオブジェクト D は Minor GC での調査範囲外で. 10∼13 行目に示すように参照先オブジェクト ref obj が New/Tenured 領域内である場合は，. ある Tenured 領域内にあるため何も行わない．ここまでのオブジェクト移動状況を図 8 (b). 現在対象としている Reference 型 Explicit メモリ ref em に ref obj を移動させる．なお，11. に示す．次に，移動したオブジェクト E からの参照先を調べると，オブジェクト F への直. および 15 行目に示すように，ref obj が ref em もしくは New/Tenured 領域内のオブジェク. 接参照が存在することが分かる．オブジェクト F も Tenured 領域への promotion 対象であ. トである場合，ref obj からの参照先を調べるようにするため，ref obj を oop stack に push. るため，ReferenceExplicitMemory に移動させる（図 8 (c) に示すオブジェクト配置）．次. する．また，17∼18 行目に示すように，ref obj が permanent 領域もしくは他の Explicit. の繰返しで，オブジェクト F からオブジェクト G への参照が見つかるが，オブジェクト. メモリ内オブジェクトである場合は，別途用意した pending oop stack に push し，25∼26. G は promotion 対象ではないため，移動先は New 領域の Survivor 領域内である．移動. 行目に示すように Reference 型 Explicit メモリへの移動処理終了直後に pending oop stack. したオブジェクト G から参照可能なオブジェクトは存在しないため，Minor GC 処理のう. に push されたオブジェクトの marking 処理を再開する．pending oop stack の導入によ. ち，Reference 型 Explicit メモリへの移動処理をともなう部分はここで終了し，あとは通常. り，Reference 型 Explicit メモリへの移動処理中に，Permanent 領域や他の Explicit メモ. の Minor GC 処理を続行する．なお，ReferenceExplicitMemory 内のオブジェクト B から. リ内オブジェクトの参照先をたどることはないため，これらの領域を介して間接参照可能な. 間接的に参照可能なオブジェクト H は，通常の Minor GC 処理での処理対象となるため，. New/Tenured 領域内オブジェクトが移動することはない．. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(10) 1702. Java における明示的メモリ管理. 図 10 Major GC における Reference 型 Explicit メモリへの移動 Fig. 10 Image of object movement to ReferenceExplicitMemory by Major GC.. 図 9 Major GC における Reference 型 Explicit メモリへの移動アルゴリズム Fig. 9 Algorithm of object movement to ReferenceExplicitMemory by Major GC.. ることが分かる．オブジェクト E は New 領域内オブジェクトであるため，oop stack に E を push した後，Explicit メモリに移動させる．また，オブジェクト G はオブジェクト B 同. 図 10 に Major GC における Reference 型 Explicit メモリへのオブジェクトの移動例を. 様 Permanent 領域内オブジェクトであるため，pending oop stack に push される．ここま. 示す．図 8 同様，アルファベットを内包する丸印はオブジェクトを表し，オブジェクト間. での状態を図 10 (b) に示す．オブジェクト E からの参照先は存在しないため，Reference-. の矢印は参照関係を示している．また，メモリ種別として，図 8 に示した New，Tenured，. ExplicitMemory への移動処理を兼ねた marking は終了する．次に，pending oop stack に. ReferenceEM に加え，図中 Perm で示す Java ヒープメモリの Permanent 領域を加えて. push されているオブジェクト B と G の参照先について処理を行う．すでに移動処理は終. いる．まず，ReferenceExplicitMemory 内のオブジェクト A からオブジェクト marking. 了しているため，オブジェクト G から参照可能なオブジェクト D と F は marking のみが. を開始し，oop stack にオブジェクト A 自身を push する．次に，pop されたオブジェク. 行われる．ここまでの状態を図 10 (c) に示す．. ト A の参照先オブジェクト B と C について，その参照先を調べる．オブジェクト B は. 3.4 Explicit メモリの削除. Permanent 領域内オブジェクトであるため，pending oop stack に push される．オブジェ. Explicit メモリを削除する API である reclaim メソッドの指示によって，対象 Explicit. クト C は，Tenured 領域内オブジェクトであるため，oop stack にオブジェクト C を push. メモリを領域内のオブジェクトごと削除する．その際，削除後のプログラム実行に影響を与. した後，Explicit メモリに移動させる．ここで，oop stack にはオブジェクト C のみが push. えないようにするため，live である可能性があるオブジェクトは削除対象外の Explicit メ. されているため，オブジェクト C からの参照先を調べると，オブジェクト E と G が存在す. モリに移動させる．本論文では，削除対象外メモリとして，Java ヒープメモリを選択して. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(11) 1703. Java における明示的メモリ管理. メモリが入る．Java ヒープメモリはつねに削除対象外メモリである．3 行目において Java ヒープメモリ内のオブジェクト 1 と 2 が調査対象となる．4 行目および 5 行目において，削 除対象外メモリ内のオブジェクト 1 から削除対象メモリ内オブジェクト 3 への参照が検出 され，6 行目においてオブジェクト 3 を Java ヒープメモリにコピーし，7 行目で参照関係 を修正すると図 12 (b) のようになる．オブジェクト 2 からは参照するオブジェクトがない ため，12 行目に進み，オブジェクト 3 が移動したため，再び 2 行目の処理に戻る．2 回目 の図 11 の 2∼5 行目の処理では，Java ヒープメモリ内に移動したオブジェクト 3 からオブ ジェクト 4 への参照が検出されるため，6 行目の処理でオブジェクト 4 も Java ヒープメモ 図 11 Explicit メモリ削除処理のアルゴリズム Fig. 11 Reclamation Algorithm of ExplicitMemory.. リにコピーされる．7 行目の処理で参照関係を修正すると図 12 (c) のようになる．再び 12 行目を実行し，オブジェクト 4 が移動したため，2∼11 行の処理を繰り返すが，削除対象 外領域である Java ヒープメモリから Explicit メモリへの参照は存在しないため，14 行目 の削除処理に進んで終了となる．オブジェクトの参照関係は図 12 (a) と (c) でまったく同 じであるため，以後の Java プログラムの実行には影響は出ない．もし，図 12 (a) の状態で. Explicit メモリとその内部オブジェクトを削除した場合，オブジェクト 1 からの参照は不正 な参照となり，その後の実行結果を保証することはできない． 図 11 に示す Explicit メモリ削除アルゴリズムの 3 行目において，調査対象オブジェクト は region 内のオブジェクト，すなわち削除対象外領域の全オブジェクトであるが，全オブ ジェクトの参照先を調査するとそのオーバヘッドが大きすぎる．そこで，Minor GC 同様， バリアセットの利用による調査領域の限定を行うことにした．ただし，Hotspot VM にお 図 12 Explicit メモリの安全な削除 Fig. 12 Reclamation image of ExplicitMemory.. けるバリアセットは Minor GC 処理の高速化のための構造であり，3.2.1 項で述べたように バリアセットを拡張したとしても New 領域への参照有無しか表現できない．そこで，バリ アセットが持つ値を拡張し，参照なし，参照に変化あり，New 領域への参照ありの状態に. いる．Explicit メモリ内オブジェクトのうち少なくとも dead オブジェクトであると判断で. 加えて，以下の 3 つの状態も持てるようにした．. きるのは，削除対象外メモリから参照できないオブジェクトであり，残りのオブジェクトは. • Explicit メモリ領域から New 領域への参照を持つオブジェクトが存在する（java new）. 以後のプログラム実行で必要とされる可能性がある．よって，このようなオブジェクト群は. • Explicit メ モ リ 領 域 か ら Tenured 領 域 へ の 参 照 を 持 つ オ ブ ジェク ト が 存 在 す る. すべて削除対象外メモリに移動させる必要がある．図 11 に Explicit メモリ領域削除処理. （java not new）. • Java ヒープ領域から Explicit メモリ領域への参照か，ある Explicit メモリ領域から別. のアルゴリズムを示す． このアルゴリズムを，図 12 を用いて説明する．図 12 には，Java ヒープメモリとすで に生成された Explicit メモリが示されており，それぞれ内部にオブジェクト 1∼4 が存在す. の Explicit メモリ領域への参照を持つオブジェクトが存在する（explicit mem） なお，加えた 3 つの状態は排他ではなく，同時に状態を保持できるよう工夫した．つま. る．オブジェクト間の矢印は参照関係である．図 12 (a) の初期状態として示すメモリ状態か. り，バリアセットの 1 カードに対応する領域から，New 領域への参照と Explicit メモリ領. ら，Explicit メモリの削除を試みる．まず，図 11 の 2 行目において region に Java ヒープ. 域への参照があるという 2 つの状態を同時に表現可能ということである．. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(12) 1704. Java における明示的メモリ管理. 図 14 ExplicitHeapCard のイメージ Fig. 14 Image of ExplicitHeapCard.. 図 13 ExplicitHeapReferenceArray のイメージ Fig. 13 Image of ExplicitHeapReferenceArray.. メモリ 1 と 2 への参照があるため「d」となっている． このバリアセットの値の拡張により，Explicit メモリへの参照がある可能性があるかどう. ExplicitHeapReferenceArray の導入で，図 11 の 3 行目で obj になりうるオブジェクト. かは分かるようになるが，削除対象 Explicit メモリへの参照があるかどうかまでは分からな. の数を減らすことができたが，4∼8 行に示す処理において，バリアセット上の調査領域中. いため，効果的に調査領域を絞ることが難しいことが予想された．そこで，バリアセット上. のオブジェクト 1 つ 1 つの参照先 ref obj について，5 行目に示すように削除対象メモリ領. で explicit mem 状態になっている領域から，どの Explicit メモリ領域に対する参照がある. 域内オブジェクトかどうかを調べなければならない．ref obj がどの領域に存在するかは不. のかを示す ExplicitHeapReferenceArray という構造を導入した．この ExplicitHeapRef-. 明であるため，所属領域調査を高速に行う仕組みが必要である．そこで，仮想メモリ空間. erenceArray は，バリアセットのカードと 1 対 1 に対応しており，1 カードに対応する領. を 4 KB の領域に分割し，バリアセット同様 1 つの領域をカードと定義したバリアセットと. 域から 1 つの Explicit メモリ領域に参照がある場合は，その ExplicitMemory オブジェ. は別の ExplicitHeapCard セットを導入した．1 カードに対応する領域を 4 KB としたのは，. クトの ID が入る．この処理は，図 6 に示す GC での移動処理のアルゴリズム中 16 行目. Explicit メモリ領域の取得は mmap 系関数による取得，すなわちページ単位の領域確保で. のバリアセットの補正時に行う．なお，複数の Explicit メモリ領域に対する参照がある場. あり，多くのシステムにおけるページ単位は 4 KB であることによる．ExplicitHeapCard. 合は dirty 状態とし，全 Explicit メモリへの参照があるものと見なす．本構造の導入によ. に対して，カードが対応する領域が Explicit メモリ領域である場合は対応する Explicit メ. り，ある ExplicitMemory オブジェクトに対して領域削除指示が行われた場合，図 11 の. モリオブジェクトの ID 値，Java ヒープメモリ領域である場合は New 領域・Tenured 領域・. 3 行目において調査対象オブジェクトを決める際に，まずバリアセット上で dirty 状態か. Permanent 領域を表す値を入れることにより，任意のアドレスから所属する領域を識別で. explicit mem 状態である部分を見つけ，対応する ExplicitHeapReferenceArray からその. きるようにした．図 14 に ExplicitHeapCard セットのイメージを示す．仮想メモリ空間上. 参照先を調べることにより，削除対象の Explicit メモリ領域への参照があるかどうかを判. で Java ヒープ領域，Explicit メモリ領域 1 と 2 が確保されている場合，図に示すように. 断できるため，調査領域を大幅に限定できる．図 13 に ExplicitHeapReferenceArray のイ. ExplicitHeapCard 上で対応する部分が Java ヒープ領域に対応する値や Explicit メモリオブ. メージを示す．仮想メモリ空間上に 3 つの Explicit メモリ領域が生成されており，内部の. ジェクトの ID 値となる．本構造の導入により，図 11 の 5 行目の処理は，ExplicitHeapCard. 丸印はオブジェクトを表している．また，オブジェクト間の矢印は参照関係を表している．. を用いた判定となり，検索処理を行った場合に対して高速化されることが期待できる．. ExplicitHeapReferenceArray 中で数値が入っている部分は，対応するメモリからその番号 を持つ Explicit メモリへの参照のみがあることを示しており，たとえば左側の「2」の値が. 4. 性 能 評 価. 入っている部分に対応する Explicit メモリ 1 内の領域からは Explicit メモリ 2 への参照の. 本章では，提案する明示的メモリ管理を利用した際の Minor GC 時間および Explicit. みが存在する．また， 「d」が入っている部分は，対応する領域から複数の領域への参照ある. メモリ領域の解放時間に関する基礎評価，および SPECjvm98 ベンチマークの 209.db，. ことを示している．この例では対応する Explicit メモリ 3 内のオブジェクトから Explicit. SPECjvm2008 ベンチマークの compress，derby，serial，xml，SPECjbb2005 ベンチマー. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(13) 1705. Java における明示的メモリ管理. ク，アプリケーションサーバ Tomcat を用いた性能評価を行った結果について述べる．な お，SPECjvm98，SPECjvm2008 には他にも多数のベンチマークプログラムが含まれてい るが，本論文で想定している業務プログラムへの適用において，その要素となりうる処理か どうかを考慮した結果，前述の 5 つのプログラムを選択することにした． 評価環境としては，CPU は Intel Xeon 2.40 GHz（周波数 2.4 GHz，NetBurst アーキテ クチャ，シングルコア）プロセッサを 2CPU，メインメモリは 2 GB，OS は Linux（Cen-. tOS4.4）を搭載したマルチプロセッサシステムを用いた．なお，評価で用いた Java 仮想マ シンは，オリジナルの Hotspot VM（JDK5.0 update 5）と，JDK5.0 update 5 において本 論文で提案する Explicit メモリを利用可能とした JavaVM であり，両 VM とも ServerVM モードで動作させた．また，各評価では，Explicit メモリを使用した場合（以後，JVM-EH）. 図 15 Minor GC 時間 Fig. 15 Execution time of Minor GC.. と使用しない場合（以後，JVM）で比較を行うが，Explicit メモリを使用しない場合は，. Explicit メモリを使用した場合の Java ヒープメモリサイズと Explicit メモリ領域サイズを 合計したサイズを Java ヒープサイズとして評価を行った．. 4.1 Explicit メモリ利用時の基礎評価 本節では Explicit メモリの確保，オブジェクトの移動が発生する Minor GC の性能およ び Explicit メモリ解放処理時間といった基礎評価を行った結果について述べる．Minor GC 性能の評価では，Explicit メモリに移動するオブジェクト量を {0.25 Mbytes（以下 MB），. 0.5 MB，1 MB，2 MB，4 MB} と変化させて評価する．なお，移動するオブジェクトは同一 サイズのオブジェクトをノードとした線形リストである．Minor GC が発生すると，JVM ではリストは Tenured 領域に移動し，JVM-EH では Explicit メモリに移動する．Explicit メモリ解放における性能評価では，Explicit メモリに 4 MB のリストが存在する状態を想定. 図 16 Explicit メモリ解放時間 Fig. 16 Execution time of ExplicitMemory reclamation.. し，その Explicit メモリを解放する際の解放対象外メモリへの移動量を {0.25 MB，0.5 MB，. 1 MB，2 MB，4 MB} と変化させて評価する． Minor GC 時間の測定結果を図 15 に示す．図 15 は JVM と JVM-EH に関して，移動. 図 16 は JVM-EH において，EM 解放処理で解放対象外領域へのオブジェクト移動量に 対する処理時間を示したグラフである．図 15 と図 16 を比較すると，安全な Explicit メモ. するオブジェクト量に対する Minor GC の処理時間を示したグラフである．JVM-EH では. リ解放の処理時間は Minor GC の約 1/10 である．解放の際，解放対象外領域へ移動するオ. JVM に比べ Explicit メモリへオブジェクトを移動するために一定のオーバヘッドを要して. ブジェクト量に比例して，処理時間は増大している．また，1 つの Explicit メモリを確保す. いることが分かる．このオーバヘッドは移動するオブジェクト量に依存せず，Minor GC は. る処理時間は 1 ミリ秒未満であった．. オブジェクトの移動量に比例して処理時間が大きくなっている．そのため，移動するオブ. 4.2 SPECjvm2008 での評価. ジェクト量が大きくなるほど，JVM-EH のオーバヘッドは相対的に小さくなる．オブジェ. 本節では，SPECjvm2008 ベンチマークから，compress，derby，serial，xml（valida-. クト移動量が 4 MB の場合，JVM-EH は JVM に比べて，Minor GC 時間が約 4.6%増大し. tion）を選択し，Context 型 Explicit メモリを適用した際の，Tenured 領域および Explicit. ている．. メモリ領域の使用量についての評価結果について述べる．各プログラムの処理概要について. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(14) 1706. Java における明示的メモリ管理 表 1 SPECjvm2008 での評価環境 Table 1 Execution environment of selected programs from SPECjvm2008.. Program compress derby serial xml.validation. Java ヒープ 384 MB 128 MB 128 MB 384 MB. Explicit メモリ 128 MB 384 MB 384 MB 128 MB. スレッド数. 5 2 5 5. は，compress は圧縮・伸長処理，derby はデータベース操作，serial はオブジェクトシリ アライズ，xml（validation）は XML の検査であり，評価環境は表 1 に示すとおりである． これらのプログラムを選択したのは，それぞれ業務プログラムの一部に近い処理と考えら. 図 17 SPECjvm2008 の xml.validation の疑似コード Fig. 17 Main part of xml.validation in SPECjvm2008.. れるためである．なお，xml には valiation 以外に transform というプログラムも含まれる が，本評価で用いた JDK5.0 ではクラスライブラリのバグによりマルチスレッド動作ができ ないとのマニュアル記述があるため，評価から外した．SPECjvm2008 では，各プログラム とも，評価で使用するデータの準備部分と，各プログラムの処理本体から構成されており， 処理本体部分は利用可能プロセッサ数もしくはオプションで指定したスレッド数で実行さ れる．ベンチマークとして得られる結果は，処理本体部分を評価時間（240 秒）内に何回繰 り返せるかを計測し，これを 1 分間での実行回数に正規化したスループット性能（ops/m:. operations per minute）である． 本評価において，Explicit メモリを利用可能とするにあたり，各プログラムに対して，デー タ準備部分で 1 つの Context 型 Explicit メモリ，処理本体でスレッドごとに 1 つの Context 型 Explicit メモリを生成し，処理本体が 1 回終了するごとに各スレッドごとに Context 型. Explicit メモリを削除するよう修正を行った．ただし，serial に関しては，生成データの相 互参照性が強く，処理本体で Explicit メモリの削除処理を行うと，ほとんどすべてのオブ. 図 18 SPECjvm2008 における Tenured 領域の使用量 Fig. 18 Used size of Tenured region in the evaluation of SPECjvm2008.. ジェクトが削除対象外メモリ（本評価では Java ヒープメモリに移動させた）に移動してし まうため，領域削除指示は入れずに評価を行っている．図 17 に，xml（validation）にお. GC が Major GC となってしまうためであり，動作スレッド数を減少させて生成データ量. ける処理本体部分の修正例を示す．図 17 中 4，5，7，8 行目が Context 型 Explicit メモリ. を減少させることによって，Major GC が多発しない普通の実行状態となるようにしてい. 利用のための記述である．なお，評価にあたっては，各プログラムでのデータ生成パターン. る．なお，規定の方法では評価時間は 240 秒であるが，本評価ではこれを 10 回（オプショ. が大きく異なることを考慮し，Java ヒープサイズと Explicit ヒープサイズを表 1 に示すよ. ン -i 10 を付加）連続で実行させた．. うに配分した．Explicit メモリを使わない場合の Java ヒープサイズは 512 MB とし，利用. 図 18，図 19 に Tenured 領域使用量，Explicit メモリ使用量の評価結果を示す．評価の結. するメモリサイズは同一となるようにした．表 1 において，derby での動作スレッド数を他. 果，提案手法を用いない評価（各プログラムの JVM）において Major GC が発生したのは. よりも少ない 2 としたのは，本ベンチマークのみ，スレッド数 5 とした場合ほぼすべての. derby，serial，xml.validation の 3 プログラムであった．derby（JVM）と serial（JVM）. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
(15) 1707. Java における明示的メモリ管理. 用いたオブジェクト移動処理を行うが，その処理オーバヘッドが大きいため，GC 処理時間 が増加したと考えている．最後に，Explicit メモリ削除時間については，derby では 0.002∼. 0.004 秒，xml.validation では 0.002∼0.02 秒であり，発生タイミングにより処理時間に大 きな差が見られたものの，Minor GC 処理時間よりは短い結果となった． また，Major GC が発生しなかった compress（JVM）に関しては，Tenured 領域の使用 量はほぼ一定値であり，提案手法を適用しても Major GC 削減効果は得られない．よって，. compress のようなアプリケーションに対しては，提案手法の適用は不適切と考えることが できる．ただ，提案手法を適用した場合は，図 18 の compress（JVM-EH）に示すように，. Tenured 領域の使用量を大きく減少させることができている．実際の業務においては，同 時に行われる他の処理によって，Tenured 領域の使用量が増加して Major GC が発生する 図 19 SPECjvm2008 における Explicit メモリの使用量 Fig. 19 Used size of ExplicitMemory in the evaluation of SPECjvm2008.. ことも予想されるため，Tenured 領域の使用量を減少させることはシステム全体にとって 好影響を与えるものと思われる．なお，スループット性能は約 3%の低下，GC 処理時間は. JVM の 0.005 秒に対して JVM-EH では 0.008 秒，領域削除時間は 0.001 秒前後と，他の では実行開始直後に Major GC が発生するが，図 18 より，Tenured 領域の使用量が大き く減少するのではなく，serial では約 160 MB，derby では約 200 MB のデータが残ること が分かる．両プログラムとも，Major GC 発生後は実行終了まで Tenured 領域使用量の増. プログラムと同様の傾向であった．. 4.3 SPECjbb2005 の評価 次に，SPECjbb2005 ベンチマークを用いた Context 型 Explicit メモリの評価結果につい. 加は見られない．なお，Major GC 発生回数は，serial（JVM）では 1 回，derby（JVM）. て述べる．本評価においては，JVM-EH での Java ヒープメモリサイズは 768 MB，Explicit. では 3 回であった．一方，xml.validation（JVM）においては，実行中は徐々に Tenured. メモリのサイズは 256 MB とし，JVM での Java ヒープメモリサイズは 1,024 MB とした．. 領域使用量が増加する傾向であり，2 回の Major GC 発生によって，大幅に Tenured 領域. SPECjbb2005 ベンチマークは，商取引をモデルとしたベンチマークであり，商品の注文，. 使用量が減少している点が上記 2 つのプログラムと異なる．この相違点は，プログラムに. 支払い，配送などの処理を Transaction と見なし，これを単位時間あたりどれだけ処理で. よって，Tenured 領域に移動するオブジェクトの寿命が異なることを示している．すなわ. きるかを計測することができる．評価にあたり，本ベンチマークで生成されるインスタン. ち，derby，serial においては長寿命オブジェクト，xml.validation では中寿命オブジェク. スの合計サイズが大きい Company，Warehouse，Item，Stock，Customer クラスのオブ. トが Tenured 領域に配置されていることを示している．このようなプログラムに対して提. ジェクト群と，Transaction 処理実行中に生成されるテンポラリオブジェクトが，図 20 に. 案手法を適用すれば，Major GC の削減効果が期待でき，実際に適用した結果，Major GC. 示すようなメモリ配置になるようプログラム修正を行った．なお，Explicit メモリの削除に. の発生を 0 回とすることができた．提案手法を適用した際のスループット性能は，最大で. ついては，各 Transaction 実行スレッドが Transaction の合間に Explicit メモリの合計使. 約 3%の低下であった．GC 処理時間については，JVM での平均 Minor GC 処理時間は. 用量を取得し，使用量が 210 MB に達した時点で Explicit メモリの削除指示を実行するよ. derby では 0.005 秒，serial では 0.002 秒，xml.validation では 0.026 秒であったのに対し. うにプログラムを修正した．. て，JVM-EH では derby で 0.005 秒，serial で 0.004 秒，xml.validation で 0.047 秒とな. 4.3.1 規定の方法での評価. り，serial と xml.validation では GC 処理時間が大きく増加していた．両プログラムとも，. まず，規定の実行方法で評価した結果について述べる．評価環境が 2 プロセッサのシステム. 図 19 より Explicit メモリの使用量が比較的大きく変動しており，Explicit メモリへの移動. であるため，実行スレッド数を示す Warehouse 数を 1 から 8 まで変化させて計測を行った．. が多数発生していることが分かる．Context 型 Expicit メモリ使用時は，移動先管理配列を. なお，各 Warehouse の実行時間は規定時間どおりであり，使用 CPU 数未満の Warehouse. 情報処理学会論文誌. Vol. 50. No. 7. 1693–1715 (July 2009). c 2009 Information Processing Society of Japan .
図
+7
関連したドキュメント
上述したオレフィンのヨードスルホン化反応における
このように，先行研究において日・中両母語話
そのような発話を整合的に理解し、受け入れようとするなら、そこに何ら
方法 理論的妥当性および先行研究の結果に基づいて，日常生活動作を構成する7動作領域より
の点を 明 らか にす るに は処 理 後の 細菌 内DNA合... に存 在す る
日頃から製造室内で行っていることを一般衛生管理計画 ①～⑩と重点 管理計画
指定管理者は、町の所有に属する備品の管理等については、
船舶の航行に伴う生物の越境移動による海洋環境への影響を抑制するための国際的規則に関して
