JP5199975B2 - メモリ管理方法、メモリ管理プログラム、及び、情報処理装置 - Google Patents

Description

本発明は、メモリ管理方法、メモリ管理プログラム、及び、情報処理装置に関するものである。

Java（登録商標）言語の処理系であるJava仮想マシン（以下、「JavaVM」という。「VM」は「Virtual Machine」の略。）は、ガベージコレクタを実装している。ガベージコレクタは、JavaVMがオブジェクトを格納するために確保するメモリ領域（以下、「Javaヒープ領域」という。）を管理し、プログラム実行中に動的に生成したオブジェクト（が割当てられたメモリ領域）のうち、不要になったオブジェクト（が割当てられたメモリ領域）をガベージコレクション（以下、「GC」という。「GC」は、「garbage collection」の略。）によって動的に解放する（自動解放機能）。説明の便宜上、メモリ領域の解放を、そのメモリ領域に格納されているオブジェクトの解放として説明する場合がある。

このGCの方式の１つに、世代別GCがある。GCの方式として世代別GCを採用しているJavaVMでは、Javaヒープ領域をNew領域とOld領域のように世代別に分けている。さらに、New領域をEden領域とSurvivor領域に、Survivor領域をFrom領域とTo領域のように分けている。

プログラム実行中に動的に生成されたオブジェクトは、最初、Eden領域に格納される。Eden領域が枯渇した場合には、ガベージコレクタが、アプリケーションプログラムの実行停止時間が短時間で済む、New領域のみを対象としたCopyGCを実行する。このCopyGCでは、レジスタ、実行時スタック、グローバル変数といったルートセットからオブジェクト参照を順次辿ることによって到達可能なオブジェクトのうち、Eden領域に格納されたオブジェクト、及び、From領域に格納されたオブジェクトをコピー先の領域にコピーする。ここで、コピー先の領域は、コピー対象のオブジェクトが一定回数以上のCopyGCを経たオブジェクト、即ち、長命なオブジェクトの場合にはOld領域である。また、一定回数以上のCopyGCを経ていないオブジェクト、即ち、まだ長命であるか否かわからないオブジェクトの場合にはTo領域である。そして、コピーされることのなかったオブジェクトを不要なオブジェクトとして解放する。なお、CopyGCの終了後には、次回のCopyGCに備え、From領域とTo領域の役割を交代する。

他方、Old領域が枯渇した場合には、ガベージコレクタが、アプリケーションプログラムの実行停止時間が長時間に及ぶ、New領域とOld領域の両方を含む全領域を対象としたFullGCを実行する。このFullGCでは、ルートセットからオブジェクト参照を順次辿ることによって到達可能なオブジェクトに対して、プログラムの実行に必要なオブジェクトであることを示す印をつけていく。そして、ルートセットから到達可能なオブジェクトを全て辿った後で、印のついていないオブジェクトを不要なオブジェクトとして解放する。

近年、先に説明したJava を基盤としたシステム（以下、「Javaシステム」という。）は、金融系や基幹系といった２４時間、３６５日、正常に機能し続けなければならない等のミッションクリティカルな分野でも利用されることが多くなっている。また、Javaシステムは大規模化、複雑化の傾向にあり、扱うデータ量も増加している。しかし、Javaヒープ領域を大きくすると、ガベージコレクタが処理しなければならないデータ量も多くなるため、GCの発生による業務プログラムの実行停止時間が長時間化する傾向にある。そのため、JavaシステムにおけるGCの発生、特に、FullGCの発生が大きな問題の１つになっている。

この問題を解決する方法として、特許文献１に開示されている方法が知られている。特許文献１に開示されている方法では、JavaVMは、GCによるオブジェクト解放の対象となるJavaヒープ領域の他に、GCによらないオブジェクト解放の対象となるヒープ領域（以下、「外部ヒープ領域」という。）を有する。外部ヒープ領域は、プログラム開発者によるメモリ管理が可能な領域であり、外部ヒープ領域に対するオブジェクトの生成、及び、解放は、プログラム開発者によるプログラムソースコード記述に従うようになっている。即ち、ガベージコレクタによる自動メモリ管理に対して、プログラムソースコード記述による明示的なメモリ管理（以下、「明示メモリ管理」という。）を行うことができる。

プログラム開発者は、外部ヒープ領域内の外部ヒープにオブジェクトを生成するようプログラムソースコードを記述することによって、プログラム実行中、必要に応じて外部ヒープが確保され、その外部ヒープにオブジェクトが生成される。また、外部ヒープに格納されたオブジェクトを解放するため、その外部ヒープを解放するようプログラムソースコードを記述することによって、外部ヒープの解放が実行される。外部ヒープの解放では、解放対象の外部ヒープに以降のプログラム実行において必要なオブジェクトが存在するか否かをチェックする。チェックの結果、必要なオブジェクトが存在しない場合には、その外部ヒープを解放する。また、必要なオブジェクトが存在する場合には、解放対象の外部ヒープとは別のヒープ領域にそのオブジェクトを移動した上で、その外部ヒープを解放する。そして、外部ヒープを解放することによって、その外部ヒープに格納されたオブジェクトをGCによらず解放する。長命なオブジェクトを外部ヒープに確保、及び、外部ヒープで解放することによって、Old領域の使用量が抑えられ、Old領域の枯渇によるFullGCの発生を抑止することができる。

特開２００９−３７５４７号公報

Old領域の枯渇によるFullGCの発生を抑止するために外部ヒープ領域を利用する場合、プログラム開発者は、プログラム実行時のオブジェクトの寿命を推定し、外部ヒープ領域に格納すべき長命なオブジェクトが外部ヒープ領域に格納されるように、プログラムソースコードを記述する必要がある。しかし、オジェクトの寿命を推定するためには、プログラム実行時のオブジェクトの参照関係に基づくオブジェクトのライフサイクルを考慮する必要があり、高度な知識と経験が必要である。
また、Javaシステムの大規模化や複雑化、複数人分担によるプログラム開発、及び、プログラムソースコードに記述されていない暗黙的なオブジェクト生成とオブジェクト参照の存在といった様々な理由によって、プログラム開発者が、プログラム実行時に動的に変化するオブジェクトの参照関係を予め把握することは極めて困難である。そのため、外部ヒープ領域に格納すべき長命なオブジェクトであっても、実際は外部ヒープ領域に格納できていないオブジェクトが存在する可能性がある。逆に、このようなオブジェクトを動的に検出し外部ヒープ領域に格納できれば、FullGCの発生をさらに抑止できる。

本発明の目的は、外部ヒープ領域に格納すべき長命なオブジェクトの多くを動的に検出できるようにすること、それらオブジェクトを外部ヒープ領域に格納できるようにすることである。

上記目的を達成するために、本発明は、Javaシステムのような、メモリ管理機構を有する言語処理実行システムにおいて、まず、FullGCによってOld領域で解放される長命なオブジェクトの参照関係を解析することで、参照関係のルートに当たるオブジェクト（以下、「起点オブジェクト」という。）を動的に検出する。次に、オブジェクト生成命令ごとに、そのオブジェクト生成命令によって生成した起点オブジェクトがFullGCによってOld領域で解放される割合をプロファイリングすることで、長命な起点オブジェクトを生成しているオブジェクト生成命令を検出する。そして、長命な起点オブジェクトを生成しているオブジェクト生成命令については、そのオブジェクト生成先を外部ヒープに変更し、起点オブジェクトを外部ヒープ領域に生成するようにする。さらに、起点オブジェクトから参照されているオブジェクト（以下、「メンバオブジェクト」という。）について、メンバオブジェクトがCopyGCによるNew領域からOld領域への移動対象となった場合には、起点オブジェクトが解放されることによって一緒に解放される割合の高いメンバオブジェクトを起点オブジェクトと同じ外部ヒープに移動させる。
このようにして、外部ヒープ領域に格納すべき長命なオブジェクトを外部ヒープ領域に格納することができるので、GCの発生、特に、FullGCの発生を抑止することができる。
詳細は後記する。

本発明によれば、外部ヒープ領域に格納すべき長命のオブジェクトの多くを動的に検出し、実際に外部ヒープ領域に格納することができる。

本発明の実施の形態のJavaVMが動作する計算機システム１０１の構成、及び、入出力データを示す図である。 Java言語により記述されたJavaソースファイル１０４の例を示す図である。 本発明の実施の形態のオブジェクト解析情報１２６の一例を示す図である。 本発明の実施の形態のオブジェクト生成情報テーブル３０１の一例を示す図である。 本発明の実施の形態のオブジェクトプロファイリング情報テーブル３０２の一例を示す図である。 本発明の実施の形態のメンバオブジェクト情報３０３の一例を示す図である。 本発明の実施の形態のオブジェクトプロファイリング用オブジェクトのデータ構造の一例を示す図である 本発明の実施の形態のオブジェクト種別ビットの一例を示す図である。 本発明の実施の形態の外部ヒープ１１７のデータ構造の一例を示す図である。 本発明の実施の形態のFullGC処理１７０３のステップ１８０１の処理の終了時点におけるJavaヒープ領域１１５のOld領域に格納されたオブジェクトの状態を示す図である。 本発明の実施の形態のオブジェクトプロファイリング処理１８０３のステップ１９０１からステップ１９０４までの処理を実行することによって、起点オブジェクトを特定する具体的な手順を示す図である。 本発明の実施の形態のCopyGC処理におけるメンバオブジェクトの移動の手順を説明するための図である。 本発明の実施の形態のバイトコード読み込み処理の手順を示すフローチャートである。 本発明の実施の形態のオブジェクト生成先変更処理１３０３の手順を示すフローチャートである。 本発明の実施の形態のメソッド実行処理の手順を示すフローチャートである。 本発明の実施の形態のオブジェクト生成処理１５０２の手順を示すフローチャートである。 本発明の実施の形態のGC処理１６０２の手順を示すフローチャートである。 本発明の実施の形態のFullGC処理１７０３の手順を示すフローチャートである。 本発明の実施の形態のオブジェクトプロファイリング処理１８０３の手順を示すフローチャートである。 本発明の実施の形態のメンバオブジェクト処理１９０４の手順を示すフローチャートである。 本発明の実施の形態のCopyGC処理１７０２の手順を示すフローチャートである。 本発明の実施の形態のメンバオブジェクト移動処理の手順を示すフローチャートである。 本発明の実施の形態のネットワーク構成を示す図である。

以下、本発明を実施するための形態として、JavaVMを例に、適宜図面を参照して詳細に説明する。
図１は、本発明の実施の形態のJavaVMが動作する計算機システム１０１の構成、及び、入出力データを示す図である。

計算機システム（情報処理装置）１０１では、Java言語によって記述されたJavaソースファイル１０４がJavaコンパイラ１０９によってコンパイルされることによって、JavaVM１１０がインタプリタ実行により解釈、及び、実行可能な形式であるバイトコードで記述されたJavaクラスファイル１０３が生成される。さらに、Javaクラスファイル１０３がJavaVM１１０によって実行されることで、所定の業務処理が実行される。従って、Javaクラスファイル１０３は、前記所定の業務処理を実行するためのプログラムといえる。

計算機システム１０１は、プロセッサ（制御部）１２９、主記憶（記憶部）１０７、補助記憶（記憶部）１０２、入力装置１３０、及び、出力装置１３１といったハードウェア資源を含む。プロセッサ１２９、主記憶１０７、補助記憶１０２、入力装置１３０、及び、出力装置１３１は、バス１２８を介して互いに接続される。

プロセッサ１２９は、主記憶１０７に記憶された各種プログラムを実行することによって各種処理を実行する。
主記憶１０７は、プログラム、プログラムの実行に必要な情報、及び、プログラムの処理結果を記憶する。主記憶１０７は、揮発性メモリであってもよいし、不揮発性メモリであってもよい。主記憶１０７は、Javaコンパイラ１０９、JavaVM１１０、データ領域１０８、及び、オペレーティングシステム１２７を記憶する。

補助記憶１０２は、業務処理の実行に使用されるJavaクラスファイル１０３、このJavaクラスファイル１０３を生成するためのJavaソースファイル１０４、オブジェクト解析情報１２６の保存に使用されるオブジェクト解析情報ファイル１０５、及び、JavaVM１１０の動作を制御するフラグやパラメータの閾値を記録する設定ファイル１０６を含む。

入力装置１３０は、計算機システム１０１に必要な情報を入力するためのインタフェースである。入力装置１３０は、例えば、キーボード、又は、マウスなどである。
出力装置１３１は、処理結果などの情報を外部に出力する装置である。出力装置１３１は、例えば、ディスプレイなどである。

データ領域１０８は、プログラムの実行に必要な情報、及び、プログラムの処理結果が記憶される領域である。データ領域１０８は、メソッドのバイトコードであるバイトコード情報１１２、GC対象のオブジェクト格納領域であるJavaヒープ領域（第１のメモリ領域）１１５、GC対象外のオブジェクト格納領域である外部ヒープ領域（第２のメモリ領域）１１６、及び、オブジェクトの生成に係る情報やオブジェクトのプロファイリングに係る情報などであるオブジェクト解析情報１２６を含む。外部ヒープ領域１１６は、さらに、外部ヒープ１（１１７）、外部ヒープ２（１１８）、外部ヒープ３（１１９）、・・・といったように、外部ヒープ領域１１６内で必要に応じて確保と解放が可能な領域を含む。

ここで、主記憶１０７に記憶されるJavaVM１１０について説明する。JavaVM１１０は、不要になったメモリ領域を動的に解放するメモリ管理機構を備える言語処理実行システムである。

JavaVM１１０は、バイトコード読み込み部１１１、オブジェクト生成先変更部１１３、メソッド実行部１１４、メモリ管理部１２０、及び、オブジェクト解析部１２５を含む。バイトコード読み込み部１１１、オブジェクト生成先変更部１１３、メソッド実行部１１４、メモリ管理部１２０、及び、オブジェクト解析部１２５は、プロセッサ１２９によって実行されるプログラムである。

バイトコード読み込み部１１１は、JavaVM１１０が受け付けたJavaクラスファイル１０３からメソッドのバイトコードを読み込み、データ領域１０８に当該メソッドに係るバイトコード情報１１２を生成する。その際、オブジェクト生成先変更部１１３を実行することによってバイトコード情報１１２に存在するオブジェクト生成命令のオブジェクト生成先を変更する場合や、バイトコード情報１１２に係るオブジェクト解析情報１２６を生成、更新する場合がある。バイトコード読み込み部１１１の処理の詳細は、図１３で説明する。

オブジェクト生成先変更部１１３は、オブジェクト生成情報テーブル３０１（図４参照）を参照して、オブジェクト生成命令に係るオブジェクト生成先を、適宜、Javaヒープ領域１１５から外部ヒープ領域１１６に変更する。オブジェクト生成先変更部１１３の処理の詳細は、図１４で説明する。

メソッド実行部１１４は、バイトコード情報１１２の各命令に従い、メソッドを実行する。そして、次に実行する命令がオブジェクト生成命令の場合には、オブジェクト生成部１２１にオブジェクト生成処理を要求する（オブジェクト生成処理要求）。メソッド実行部１１４は、最初、メソッドをインタプリタ実行する。一方、インタプリタ実行において実行頻度が高いメソッドについては、バイトコード情報１１２の命令列を動的にコンパイルし、メソッドをコンパイルコード実行する。なお、メソッド実行部１１４は、最初から最後までメソッドをインタプリタ実行してもよいし、最初からコンパイルコード実行してもよい。また、メソッド実行部１１４が、メソッドをコンパイルコード実行している途中で、バイトコード情報１１２が書き換えられた場合、メソッド実行部１１４は、メソッドをコンパイルコード実行するのを止め、インタプリタ実行に一旦戻り処理を継続する場合もある。メソッド実行部１１４の処理の詳細は、図１５で説明する。

メモリ管理部１２０は、JavaVM１１０で使用するメモリ領域を管理する。メモリ管理部１２０は、オブジェクト生成部１２１、及び、GC部１２２を含む。

オブジェクト生成部１２１は、メソッド実行部１１４からのオブジェクト生成処理要求を受け付けると、オブジェクト生成処理要求の内容に従い、Javaヒープ領域１１５、又は、外部ヒープ領域１１６へのオブジェクト生成を試みる。ここで、オブジェクトを生成する領域に空きがあり、オブジェクト生成に成功した場合には、生成したオブジェクトを呼び元に返却する。
一方、Javaヒープ領域１１５に空きがなく、Javaヒープ領域１１５へのオブジェクト生成に失敗した場合には、GC部１２２にGC処理を要求し（GC処理要求）、GC部１２２がGC処理を実行し、Javaヒープ領域１１５で不要になったメモリ領域を解放する。そして、再びオブジェクト生成を試み、さらに失敗した場合にはメモリ不足エラーを発生させる。
また、外部ヒープ領域１１６に空きがなく、外部ヒープ領域１１６へのオブジェクト生成に失敗した場合には、Javaヒープ領域１１５へのオブジェクト生成を試みる。さらにJavaヒープ領域１１５へのオブジェクト生成にも失敗した場合には、GC部１２２にGC処理を要求し、GC部１２２がGC処理を実行し、Javaヒープ領域１１５で不要になったメモリ領域を解放する。そして、再びオブジェクト生成を試み、さらに失敗した場合にはメモリ不足エラーを発生させる。

なお、オブジェクト生成部１２１は、生成したオブジェクトに対し、当該オブジェクト生成命令によって生成されたオブジェクトであることを識別するためのオブジェクトIDを生成したオブジェクトに記録し、当該オブジェクト生成命令によってオブジェクトを生成したことをオブジェクトプロファイリング情報テーブル３０２（図５参照）に記録する場合がある。オブジェクト生成部１２１の処理の詳細は、図１６で説明する。

GC部１２２は、CopyGC部１２４、及び、FullGC部１２３を含む。GC部１２２は、オブジェクト生成部１２１からのGC処理要求を受け付けると、New領域が枯渇している場合にはCopyGC部１２４、Old領域が枯渇している場合にはFullGC部１２３に対して、実際のGC処理を要求する。GC部１２２の処理の詳細は、図１６で説明する。

CopyGC部１２４は、GC部１２２からのGC処理要求を受け付けると、Javaヒープ領域１１５内のNew領域のみを対象としたCopyGCを実行する。その際、CopyGCによってJavaヒープ領域１１５のNew領域からOld領域の移動対象となったオブジェクトをNew領域から外部ヒープ１１７（外部ヒープ領域１１６内に確保した外部ヒープの一つであり、「外部ヒープ１」と称する場合もある。）に移動させる場合や、不要な外部ヒープ１１７を解放する場合、及び、オブジェクト生成先変更部１１３を実行することによってバイトコード情報１１２に存在するオブジェクト生成命令のオブジェクト生成先を変更する場合がある。CopyGC部１２４の処理の詳細は、図２１で説明する。

FullGC部１２３は、GC部１２２からのGC処理要求を受け付けると、Javaヒープ領域１１５内のNew領域とOld領域を含む、GC対象の全領域を対象としたFullGCを実行する。その際、オブジェクト解析部１２５を実行し、オブジェクトプロファイリング処理を実行する場合がある。FullGC部１２３の処理の詳細は、図１８で説明する。

オブジェクト解析部１２５は、FullGCによってOld領域で解放される長命なオブジェクトの参照関係を解析することで、参照関係のルートに当たる起点オブジェクトを動的に検出する。そして、オブジェクト生成命令ごとに、そのオブジェクト生成命令によって生成した起点オブジェクトがFullGCによってOld領域で解放された回数をプロファイリングする。また、起点オブジェクトから参照されているメンバオブジェクトについて、起点オブジェクトが解放されたことによってメンバオブジェクトも一緒に解放された回数をプロファイリングする。オブジェクト解析部１２５の処理の詳細は、図１９で説明する。

なお、JavaVM１１０は、動作を制御するためのフラグ（以下、「設定フラグ」という。）やパラメータの閾値（以下、「設定閾値」という。）をもつ。そして、設定フラグや設定閾値のデフォルト値は、設定ファイル１０６や入力装置１３０で指定することによって変更することができる。

JavaVM１１０は、FullGCによってOld領域で解放される長命なオブジェクトの参照関係を解析することで、外部ヒープ領域１１６に格納すべきオブジェクトを検出し、それらオブジェクトを外部ヒープ領域１１６に格納していくことで、FullGCを抑止していく。一方、FullGCによってOld領域で解放される長命なオブジェクトの参照関係の解析結果を記録したオブジェクト解析情報ファイル１０５を使用し、設定フラグによるJavaVM１１０の動作変更によって、外部ヒープ領域１１６に格納すべきオブジェクトを検出するためのオブジェクトプロファイリングを行わないようにし、JavaVM１１０の起動時からFullGCを抑止した状態で実行してもよい。

図２は、Java言語により記述されたJavaソースファイル１０４の例を示す図である。
１行目から１７行目は、Sampleクラスの内容を示している。
３行目から９行目、及び、１１行目から１５行目は、それぞれ、methodA()メソッド、及び、methodB()メソッドの処理の内容を示している。
５行目、及び、１３行目は、クラスの型がClassAであるオブジェクトをJavaヒープ領域１１５に生成することをnew演算子により指示している。また、６行目は、クラスの型がClassZであるオブジェクトをJavaヒープ領域１１５に生成することをnew演算子により指示している。これにより、例えばmethodA()を５回実行すると、クラスの型がClassAであるオブジェクトが５個、クラスの型がClassZであるオブジェクトが５個、それぞれ生成される。さらにmethodB()を１０回実行すると、クラスの型がClassAであるオブジェクトがもう１０個生成される。

ここで、methodA()とmethodB()の実行により、クラスの型が同じClassAであるオブジェクトが生成されるが、methodA()の５行目で生成を指示されたオブジェクトと、methodB()の１３行目で生成を指示されたオブジェクトとでは、クラスの型が同じClassAであっても同じようなオブジェクトの寿命になるとは限らない。一方、methodA()の実行により、methodA()の５行目で生成を指示された５個のオブジェクトについては、methodA()の同じ処理により生成されたオブジェクトであるため、同じようなオブジェクトの寿命になる可能性が高いと言える。

オブジェクトプロファイリングでは、クラスの型が同じであっても、オブジェクトの生成を指示された場所が異なるオブジェクトは区別することで、より詳細にオブジェクトをプロファイリングすることができる。

図３は、本発明の実施の形態のオブジェクト解析情報１２６の一例を示す図である。
オブジェクト解析情報１２６は、バイトコード情報１１２に係るオブジェクト解析の情報を格納しており、オブジェクト生成情報テーブル３０１、オブジェクトプロファイリング情報テーブル３０２、及び、メンバオブジェクト情報３０３を含む。メンバオブジェクト生成情報テーブル３０１、オブジェクトプロファイリング情報テーブル３０２、及び、メンバオブジェクト情報３０３の詳細は、それぞれ、図４、図５、及び、図６で説明する。

図４は、本発明の実施の形態のオブジェクト生成情報テーブル３０１の一例を示す図である。
オブジェクト生成情報テーブル３０１の各行は、オブジェクト生成命令に係る情報を格納しており、オブジェクト生成命令アドレス４０１、オブジェクトID(Identifier)４０２、クラス名４０３、及び、オブジェクト生成先４０４を含む。

オブジェクト生成命令アドレス４０１は、オブジェクト生成命令の位置を格納する。オブジェクト生成命令の位置は、例えば、図２に示すJavaソースファイル１０４の例におけるnew演算子のようなオブジェクト生成指示に対応するバイトコード情報１１２内のオブジェクト生成命令が存在するアドレスである。なお、オブジェクト解析情報１２６をオブジェクト解析情報ファイル１０５に保存する場合など、オブジェクト生成命令の位置は、バイトコード情報１１２の先頭からオブジェクト生成命令が存在する位置までのオフセットで示される場合もある。

オブジェクトID４０２は、オブジェクト生成命令ごとに割当てられる一意の値を格納する。そして、オブジェクトプロファイリング処理の対象であるオブジェクトのオブジェクトIDフィールド７０２（図７参照）に、当該オブジェクトを生成したオブジェクト生成命令に係るオブジェクトID４０２が格納される。これにより、オブジェクトがどのオブジェクト生成命令によって生成されたかを判別できる。例えば、図２に示すJavaソースファイル１０４の例において、５行目で生成を指示されたクラスの型がClassAであるオブジェクトと１３行目で生成を指示されたクラスの型がClassAであるオブジェクトでは、オブジェクトヘッダ７０１に格納されたオブジェクトIDが#0、#4といったように異なる。一方、５行目で生成を指示されたクラスの型がClassAであるオブジェクトが複数存在しても、オブジェクトの生成を指示された位置が同じであるオブジェクトでは、オブジェクトIDが#0といったように同じになる。

クラス名４０３は、オブジェクト生成命令によって生成されるオブジェクトのクラスの型の名前を格納する。

オブジェクト生成先４０４は、オブジェクト生成命令によって生成されるオブジェクトの生成先を格納する。オブジェクトの生成先は、初期状態では“Javaヒープ領域”となっているが、オブジェクト生成先変更部１１３によって、オブジェクトプロファイリング処理の結果に応じて“外部ヒープ１”などに変更される。また、オブジェクトの生成先は、“Javaヒープ固定”にすることで、オブジェクト生成先変更部１１３によって変更されないようにしたり、“指定外部ヒープ”にしたりすることで、明示メモリ管理API（明示メモリ管理を実行するAPIをいう。「API」は、「application programming interface」の略。）によって指定された外部ヒープにしたりすることも可能である。なお、明示メモリ管理APIによって指定された外部ヒープに生成されたオブジェクトは、明示メモリ管理APIによって解放され、不要な外部ヒープ１１７ごと自動的に解放されることはない。オブジェクトプロファイリング処理の詳細は、図１９で説明する。

図５は、本発明の実施の形態のオブジェクトプロファイリング情報テーブル３０２の一例を示す図である。
オブジェクトプロファイリング情報テーブル３０２は、オブジェクトID４０２に係るオブジェクトについてのオブジェクトプロファイリング処理の結果を格納しており、オブジェクトID５０１、オブジェクト生成回数５０２、オブジェクトプロファイリング回数５０３、及び、メンバオブジェクト情報アドレス５０４を含む。

オブジェクトID５０１は、オブジェクト生成情報テーブル３０１の行データとオブジェクトプロファイリング情報テーブル３０２の行データを結びつけるためのオブジェクトIDを格納する。このオブジェクトIDをキーとした検索により、このオブジェクトIDによって識別されるオブジェクトについてのオブジェクト生成情報テーブル３０１の行データとオブジェクトプロファイリング情報テーブル３０２の行データが参照可能である。ここで、例えば、オブジェクト生成情報テーブル３０１の行データに対するオブジェクトプロファイリング情報テーブル３０２の行データを予め用意する場合、オブジェクト生成情報テーブル３０１の行データとオブジェクトプロファイリング情報テーブル３０２の行データは１対１に対応するため、オブジェクト生成情報テーブル３０１とオブジェクトプロファイリング情報テーブル３０２を１つのテーブルにまとめてしまってもよい。また、オブジェクトプロファイリング情報テーブル３０２のために確保するメモリ領域を節約するために、オブジェクトID４０２で識別されるオブジェクトが初めて生成されたとき、オブジェクト生成情報テーブル３０１の行データに対するオブジェクトプロファイリング情報テーブル３０２の行データを登録するようにしてもよい。なお、本発明の実施の形態の一例では、オブジェクト生成情報テーブル３０１の行データに対するオブジェクトプロファイリング情報テーブル３０２の行データを予め用意するが、便宜上、オブジェクト生成情報テーブル３０１とオブジェクトプロファイリング情報テーブル３０２を別々のテーブルとして示す。

オブジェクト生成回数５０２は、オブジェクトID５０１で識別されるオブジェクトをオブジェクトID５０１に係るオブジェクト生成命令によって実際に生成した回数を格納する。

オブジェクトプロファイリング回数５０３は、オブジェクトID５０１で識別されるOld領域に格納してあるオブジェクトがFullGCによって解放された回数、つまり、オブジェクトID５０１で識別されるオブジェクトに対して、オブジェクトプロファイリング処理を実行した回数を格納する。オブジェクトプロファイリング処理の詳細は、図１９で説明する。

メンバオブジェクト情報アドレス５０４は、オブジェクトID５０１で識別されるオブジェクトに係るメンバオブジェクト情報３０３のアドレスを格納する。メンバオブジェクト情報３０３の詳細は、図６で説明する。

図６は、本発明の実施の形態のメンバオブジェクト情報３０３の一例を示す図である。
メンバオブジェクト情報３０３は、オブジェクトプロファイリング処理によってプロファイリングされたオブジェクトの参照関係の状況についての情報を格納しており、起点オブジェクトについての情報を格納するデータ構造（以下、「起点オブジェクトデータ構造」という。）、及び、メンバオブジェクトについての情報を格納するデータ構造（以下、「メンバオブジェクトデータ構造」という。）を含む。起点オブジェクトは、オブジェクトプロファイリング処理の起点となるOld領域に格納してあるオブジェクトであり、前回のFullGCの終了後から今回のFullGCの開始前までの間に、ルートセットや必要オブジェクトから参照されなくなったオブジェクト、又は、ルートセットや必要オブジェクトから参照されなくなった可能性の高いオブジェクトである。また、メンバオブジェクトは、起点オブジェクトからオブジェクト参照を順次辿ることによって到達可能なオブジェクトのうち、起点オブジェクトがFullGCによって解放されることによって一緒に解放されるオブジェクト、又は、一緒に解放される可能性の高いオブジェクトである。オブジェクトプロファイリング処理の詳細は、図１９で説明する。

本発明の実施の形態の一例では、メンバオブジェクト情報３０３は、起点オブジェクトデータ構造６０１、及び、メンバオブジェクトデータ構造６０２〜６０７がポインタによって接続された木構造として示す。また、図６において、起点オブジェクトデータ構造は二重線の長方形で示し、メンバオブジェクトデータ構造は一重線の長方形で示す。

起点オブジェクトデータ構造６０１は、起点オブジェクトから参照先メンバオブジェクトへの参照関係の状況を記録するために、メンバオブジェクトに対応するメンバオブジェクトデータ構造へのポインタをオブジェクト参照フィールドごとに格納する。例えば、本発明の実施の形態の一例は、起点オブジェクトデータ構造６０１が、メンバオブジェクトデータ構造６０２、及び、メンバオブジェクトデータ構造６０３をポインタによって接続していることを示す。

メンバオブジェクトデータ構造６０２〜６０７は、メンバオブジェクトから参照先メンバオブジェクトの参照関係の状況を記録するために、参照先メンバオブジェクトに対応するメンバオブジェクトデータ構造へのポインタをオブジェクト参照フィールドごとに格納する。例えば、本発明の実施の形態の一例は、メンバオブジェクトデータ構造６０３が、メンバオブジェクトデータ構造６０５とメンバオブジェクトデータ構造６０６をポインタによって接続していることを示す。なお、ポインタ６０８は、クラスの型がClassFであるオブジェクトにオブジェクト参照フィールドは存在するが、そのオブジェクト参照フィールドによって参照しているオブジェクトは記録されていないことを示す（NULL）。

また、メンバオブジェクトデータ構造６０２〜６０７は、メンバオブジェクトのクラスの型の名前と、起点オブジェクトがFullGCによって解放されたことによってメンバオブジェクトも一緒に解放された回数、つまり、起点オブジェクトに対してオブジェクトプロファイリング処理を実行したときに、メンバオブジェクトに対してもオブジェクトプロファイリング処理を実行した回数（以下、「メンバオブジェクトプロファイリング回数」という。）を格納する。例えば、本発明の実施の形態の一例は、起点オブジェクトデータ構造６０１によって示される起点オブジェクトがFullGCによって解放されたことによってメンバオブジェクトデータ構造６０５によって示されるClassEのメンバオブジェクトも一緒に解放された回数が２回であることを示す。
ここで、ポインタに付された数字は、便宜上のメンバオブジェクト適合率を示す。メンバオブジェクト適合率は、起点オブジェクトがFullGCによって解放されたことによってメンバオブジェクトも一緒に解放された割合である。例えば、メンバオブジェクトデータ構造６０６によって示されるClassFのメンバオブジェクト適合率は、メンバオブジェクトデータ構造６０１によって示されるClassAの起点オブジェクトが４回解放されたうちClassFのメンバオブジェクトは３回解放されたので、0.75になる。また、メンバオブジェクトデータ構造６０７によって示されるClassGのメンバオブジェクト適合率は、メンバオブジェクトデータ構造６０１によって示されるClassAの起点オブジェクトが４回解放されたうちClassGのメンバオブジェクトは１回解放されたので、0.25になる。
また、破線の囲み線はメンバオブジェクト適合率が0.6である便宜上の境界を示しており、破線で囲まれた内側は、メンバオブジェクト適合率が0.6以上であることを示している。

なお、メンバオブジェクト情報アドレス５０４には、メンバオブジェクト情報３０３のアドレスとして、起点オブジェクトデータ構造のアドレスが格納される。例えば、本発明の実施の形態の一例は、オブジェクトID５０１に格納されているオブジェクトIDが#4であるオブジェクトに対するメンバオブジェクト情報アドレス５０４に、起点オブジェクトデータ構造６０１のアドレスである0x81b2e23cが格納されていることを示す。また、本発明の実施の形態では一例として、起点オブジェクトデータ構造６０１がオブジェクトID（下付き数字の「４」）、オブジェクトのクラスの型の名前（ClassA）、プロファイリングの実行回数（括弧内の数字の「４」）を格納するように便宜上記載してある。

図７は、本発明の実施の形態のオブジェクトプロファイリング用オブジェクトのデータ構造の一例を示す図である。オブジェクトプロファイリング用オブジェクトは、オブジェクトヘッダ７０１、オブジェクトIDフィールド７０２、及び、オブジェクトデータ７０３から構成される。オブジェクトプロファイリング用オブジェクトとは、オブジェクトプロファイリング処理の対象となるオブジェクトである。

オブジェクトヘッダ７０１は、オブジェクトの管理情報である。
オブジェクトIDフィールド７０２は、オブジェクトを識別するためのオブジェクトIDを格納する。このオブジェクトIDは、当該オブジェクトを生成したオブジェクト生成命令に係るオブジェクトID４０２である。なお、オブジェクトプロファイリング処理の対象ではない通常オブジェクトのデータ構造は、オブジェクトヘッダ７０１とオブジェクトデータ７０３で構成される。また、オブジェクトプロファイリング処理の対象であっても、オブジェクトヘッダ７０１の空き領域やオブジェクトデータ７０３、及び、オブジェクトのデータ構造以外の領域にオブジェクトIDを格納するなどしてオブジェクトを識別できれば、オブジェクトIDフィールドのための領域を別途確保する必要はない。
オブジェクトデータ７０３は、オブジェクトのデータ本体である。

なお、オブジェクトへのポインタの下位数ビットは、オブジェクトヘッダ７０１のサイズに応じて０とすることができるため、ビットフラグとして使用可能である。例えば、オブジェクトヘッダ７０１のサイズが８バイトである場合、オブジェクトへのポインタの下位３ビットは０になる。本発明の実施の形態では、オブジェクトへのポインタの下位数ビットをビットフラグとして使用する場合がある。

図８は、本発明の実施の形態のオブジェクト種別ビットの一例を示す図である。
オブジェクト種別ビット８０２の値は、オブジェクト種別８０１に対応する。本発明の実施の形態では、オブジェクトヘッダ７０１に含まれる２ビットをオブジェクト種別ビットとして使用する。

具体的には、オブジェクト種別ビット８０２が“００”の場合には、GC処理やオブジェクトプロファイリング処理において未解析なオブジェクトである“未解析”オブジェクトであることを示す。
また、オブジェクト種別ビット８０２が“０１”の場合には、FullGC処理においてプログラムの実行に必要なオブジェクトであると判定済みの“必要”オブジェクトであることを示す。
同様に、オブジェクト種別ビット８０２が“１０”の場合には、オブジェクトプロファイリング処理の起点となるオブジェクトであり、前回のFullGCから今回のFullGCまでの間に、必要オブジェクトから参照されなくなったオブジェクト、又は、必要オブジェクトから参照されなくなった可能性の高いオブジェクトである“起点”オブジェクトであることを示す。
さらに、オブジェクト種別ビット８０２が“１１”の場合には、起点オブジェクトからオブジェクト参照を順次辿ることによって到達可能なオブジェクトのうち、起点オブジェクトがFullGCによって解放されることによって一緒に解放されるオブジェクト、又は、一緒に解放される可能性の高いオブジェクトである“メンバ”オブジェクトであることを示す。

図９は、本発明の実施の形態の外部ヒープ１１７のデータ構造の一例を示す図である。外部ヒープ１１７は、外部ヒープヘッダ９０１、オブジェクト格納領域９０２から構成される。
外部ヒープヘッダ９０１は、オブジェクトの管理情報であり、外部ヒープ１１７に格納された起点オブジェクトを生成したオブジェクト生成命令に係るメンバオブジェクト参照情報アドレス５０４に格納されたメンバオブジェクト情報３０３のアドレスを格納する。
オブジェクト格納領域９０２は、オブジェクトを格納するための領域である。

図１３は、本発明の実施の形態のバイトコード読み込み処理の手順を示すフローチャートである。本処理は、プロセッサ１２９がバイトコード読み込み部１１１を処理することによって、実行される。なお、図１０〜図１２に関する説明は後記する。

プロセッサ１２９がバイトコード読み込み部１１１を実行すると、バイトコード読み込み部１１１は、まず、JavaVM１１０が受け付けたJavaクラスファイル１０３からメソッドのバイトコードを読み込み、データ領域１０８に当該メソッドに係るバイトコード情報１１２を生成する（ステップ１３０１）。

ステップ１３０１の処理の終了後には、JavaVM１１０の設定フラグを参照し、バイトコード読み込み処理時に、当該メソッドに係るバイトコード情報１１２に存在するオブジェクト生成命令のオブジェクト生成先を変更するか否かを判定する（ステップ１３０２）。

オブジェクト生成先を変更する場合には（ステップ１３０２の結果が「ＹＥＳ」）、JavaVM１１０が受け付けたオブジェクト解析情報ファイル１０５に保存してある当該メソッドに係るオブジェクト解析情報の実行結果をオブジェクト解析情報１２６に読み込み、当該メソッドに係るオブジェクトプロファイリング情報テーブル３０２に登録された行データで示されるオブジェクトに対して、オブジェクト生成先変更部１１３を実行し、オブジェクト生成先変更処理を実行する（ステップ１３０３）。

オブジェクト生成先を変更しない場合（ステップ１３０２の結果が「ＮＯ」）、又は、ステップ１３０３の処理が終了した場合には、JavaVM１１０の設定フラグを参照し、オブジェクトプロファイリングを行うか否かを判定する（ステップ１３０４）。

オブジェクトプロファイリングを行う場合には（ステップ１３０４の結果が「ＹＥＳ」）、ステップ１３０１の処理で生成したバイトコード情報１１２に係るオブジェクト解析情報１２６を生成し、バイトコード情報１１２に存在する全てのオブジェクト生成命令について、オブジェクト生成命令のアドレス、オブジェクト生成命令に割り当てられる一意のオブジェクトID、及び、オブジェクト生成命令で生成されるオブジェクトのクラス名を、それぞれ、オブジェクト生成命令アドレス４０１、オブジェクトID４０２、及び、クラス名４０３に登録する（更新も含む）。さらに、オブジェクト生成先４０４を“Javaヒープ領域”で登録する（ステップ１３０５）。ただし、ステップ１３０３の処理で、JavaVM１１０が受け付けたオブジェクト解析情報ファイル１０５に保存してある当該メソッドに係るオブジェクト解析情報の実行結果をオブジェクト解析情報１２６に反映しているオブジェクト生成命令については、ステップ１３０５の処理を行わない。

オブジェクトプロファイリングを行わない場合（ステップ１３０４の結果が「ＮＯ」）、又は、ステップ１３０５の処理の終了後には、本処理を終了する。

図１４は、本発明の実施の形態のオブジェクト生成先変更処理１３０３の手順を示すフローチャートである。本処理は、プロセッサ１２９がオブジェクト生成先変更部１１３を処理することによって、実行される。

プロセッサ１２９がオブジェクト生成先変更部１１３を実行すると、オブジェクト生成先変更部１１３は、まず、処理対象のオブジェクトプロファイリングテーブル３０２について、オブジェクトID５０１に未処理のオブジェクトIDが存在するか否かを判定する（ステップ１４０１）。

オブジェクトID５０１に未処理のオブジェクトIDが存在する場合には（ステップ１４０１の結果が「ＹＥＳ」）、当該オブジェクトIDで識別されるオブジェクトのオブジェクト生成回数５０２が、JavaVM１１０の設定閾値（第１の閾値）以上であるか否かを判定する（ステップ１４０２）。このステップ１４０２では、オブジェクト生成先を変更するか否かを判定するのに十分な回数のオブジェクト生成が実施済みか否かを判定する。例えば、オブジェクト生成回数の設定閾値が1000回の場合、オブジェクトID５０１が#0であるオブジェクト生成命令は、オブジェクト生成回数５０２が5872回であることから（図５参照）、オブジェクト生成先を変更するか否かを判定するのに十分な回数のオブジェクト生成を実施済みと判定できる。一方、オブジェクトID５０１が#104であるオブジェクト生成命令は、オブジェクト生成回数５０２が950回であることから（図５参照）、オブジェクト生成先を変更するか否かを判定するのに十分な回数のオブジェクト生成を実施済みでないと判定できる。

オブジェクト生成回数５０２が設定閾値以上である場合には（ステップ１４０２の結果が「ＹＥＳ」）、当該オブジェクトIDに係るオブジェクト生成回数５０２に対するオブジェクトプロファイリング回数５０３が、JavaVM１１０の設定閾値（第２の閾値）以上であるか否かを判定する（ステップ１４０３）。このステップ１４０３では、当該オブジェクトIDに係るオブジェクト生成命令によって生成されたオブジェクトが、FullGCによって解放された割合の高さ、つまり、当該オブジェクト生成命令によって生成されたオブジェクトが、外部ヒープ領域に格納すべき長命なオブジェクトになる割合の高さに基づき、当該オブジェクト生成命令のオブジェクト生成先を外部ヒープ領域に変更するべきか否かを判定する。例えば、オブジェクト生成回数に対するオブジェクトプロファイリング回数の設定閾値（割合）が0.50の場合、オブジェクトID５０１が#0であるオブジェクト生成命令によって生成されたオブジェクトは5872個であり（図５参照）、そのうち、5830個がFullGCによって解放されたので、FullGCによって解放された割合は0.99であり、設定閾値より大きいので、当該オブジェクト生成命令のオブジェクト生成先を外部ヒープ領域に変更するべきと判定できる。一方、オブジェクトID５０１が#103であるオブジェクト生成命令によって生成されたオブジェクトは10281個であり、そのうち、237個がFullGCによって解放されたので、FullGCによって解放された割合は0.02であり、設定閾値0.50より小さいので、当該オブジェクト生成命令のオブジェクト生成先を外部ヒープ領域に変更するべきではないと判定できる。

オブジェクト生成回数５０２に対するオブジェクトプロファイリング回数５０３が設定閾値以上である場合には（ステップ１４０３の結果が「ＹＥＳ」）、オブジェクト生成情報テーブル３０１を参照して、当該オブジェクトIDに係るオブジェクト生成先４０４を“Javaヒープ領域”以外の、例えば、“外部ヒープ領域１”に変更する（ステップ１４０４）。

オブジェクト生成回数５０２が設定閾値以上でない場合（ステップ１４０２の結果が「ＮＯ」）、オブジェクト生成回数５０２に対するオブジェクトプロファイリング回数５０３が設定閾値以上でない場合（ステップ１４０３の結果が「ＮＯ」）、又は、ステップ１４０４の処理の終了後には、ステップ１４０１の処理に戻る。そして、未処理のオブジェクトIDに対して、本処理の実行を継続する。

オブジェクトID５０１に未処理のオブジェクトIDが存在しない場合には（ステップ１４０１の結果が「ＮＯ」）、本処理を終了する。なお、ステップ１４０２やステップ１４０３の判定では、当該オブジェクトIDに係るオブジェクトのクラスサイズなどに応じて、比較対象値に重み付けを行ってもよい。

図１５は、本発明の実施の形態のメソッド実行処理の手順を示すフローチャートである。本処理は、プロセッサ１２９がメソッド実行部１１４を処理することによって、実行される。
バイトコード読み込み部１１１が生成した実行対象メソッドに係るバイトコード情報１１２は、一つ以上の命令を含み、各命令には、命令種別が付与されている。

プロセッサ１２９がメソッド実行部１１４を実行すると、メソッド実行部１１４は、まず、実行対象のメソッドの命令種別がオブジェクト生成命令であるか否かを判定する（ステップ１５０１）。

命令種別がオブジェクト生成命令でない場合には（ステップ１５０１の結果が「ＮＯ」）、当該命令を実行する（ステップ１５０４）。
命令種別がオブジェクト生成命令である場合には（ステップ１５０１の結果が「ＹＥＳ」）、オブジェクト生成部１２１を実行し、オブジェクト生成処理を実行する（ステップ１５０２）。

ステップ１５０２の処理の終了後には、オブジェクトの生成に成功したか否かを判定する（ステップ１５０３）。
オブジェクトの生成に失敗した場合には（ステップ１５０３の結果が「ＮＯ」）、メソッドの実行を中断し、メモリ不足エラーを発生させる（ステップ１５０５）。

オブジェクトの生成に成功した場合（ステップ１５０３の結果が「ＹＥＳ」）、又は、ステップ１５０４の処理の終了後には、次に実行すべき命令があるか否かを判定する（ステップ１５０６）。
次に実行すべき命令がある場合には（ステップ１５０６の結果が「ＹＥＳ」）、ステップ１５０１の処理を実行し、メソッド実行処理を継続する。

次に実行すべき命令がない、つまり、すべての命令の処理が終了した場合には（ステップ１５０６の結果が「ＮＯ」）、又は、ステップ１５０５の処理の終了後には、本処理を終了する。

図１６は、本発明の実施の形態のオブジェクト生成処理１５０２の手順を示すフローチャートである。本処理は、プロセッサ１２９がオブジェクト生成部１２１を処理することによって、実行される。

プロセッサ１２９がオブジェクト生成部１２１を実行すると、オブジェクト生成部１２１は、まず、生成を要求されたオブジェクトを生成するのに必要な量のメモリを当該オブジェクト生成命令に係るオブジェクト生成先４０４（図４参照）に格納されたオブジェクト生成先に確保可能であるか否かを判定する。オブジェクト生成先が外部ヒープ領域１１６であり、生成を要求されたオブジェクトを生成するのに必要な量のメモリを外部ヒープ領域１１６に確保可能でない場合には、さらに、生成を要求されたオブジェクトを生成するのに必要な量のメモリをJavaヒープ領域１１５に確保可能であるか否かを判定する。（ステップ１６０１）。

生成を要求されたオブジェクトを生成するのに必要な量のメモリをオブジェクト生成先に確保できない場合には（ステップ１６０１の結果が「ＮＯ」）、Javaヒープ領域１１５の不要なメモリ領域を解放するために、GC部１２２を実行し、GC処理を実行する（ステップ１６０２）。

ステップ１６０２の処理の実行後、生成を要求されたオブジェクトを生成するのに必要な量のメモリをJavaヒープ領域１１５に確保可能であるか否かを再び判定する（ステップ１６０３）。

生成を要求されたオブジェクトを生成するのに必要な量のメモリをJavaヒープ領域１１５に確保できない場合には（ステップ１６０３の結果が「ＮＯ」）、オブジェクト生成処理の実行元にオブジェクト生成に失敗した旨を通知する（ステップ１６１１）。

生成を要求されたオブジェクトを生成するのに必要な量のメモリをオブジェクト生成先に確保可能な場合には（ステップ１６０１、又は、ステップ１６０３の結果が「ＹＥＳ」）、今回のオブジェクト生成先がどこであるかを判定する（ステップ１６０４）。

今回のオブジェクト生成先がJavaヒープ領域１１５である場合には（ステップ１６０４の結果が「Javaヒープ領域」）、JavaVM１１０の設定フラグを参照し、オブジェクトプロファイリングを行うか否かを判定する（ステップ１６０６）。

オブジェクトプロファイリングを行う場合には（ステップ１６０６の結果が「ＹＥＳ」）、オブジェクトプロファイリング用オブジェクトをJavaヒープ領域１１５に生成し、当該オブジェクト生成命令によって生成されたオブジェクトであることを識別するための当該オブジェクト生成命令に係るオブジェクトID４０２を当該オブジェクトのオブジェクトIDフィールド７０２に記録する（ステップ１６０７）。

ステップ１６０７の処理の終了後には、当該オブジェクト生成命令によってオブジェクトを生成したことを記録するために、当該オブジェクト生成命令に係るオブジェクト生成回数５０２の値に１を加算して、オブジェクトプロファイリング情報テーブル３０２を更新する（ステップ１６０９）。

今回のオブジェクト生成先が外部ヒープ領域１１６である場合には（ステップ１６０４の結果が「外部ヒープ領域」）、オブジェクト生成先となる外部ヒープ１１７を生成する。そして、外部ヒープ１１７の外部ヒープヘッダ９０１に、当該生成命令に係るメンバオブジェクト情報アドレス５０４を記録する（ステップ１６０５）。なお、外部ヒープを生成する際の初期サイズは、当該生成命令に係る起点オブジェクトのクラスサイズ、及び、当該生成命令に係り、メンバオブジェクト適合率が設定閾値以上であるメンバオブジェクトのクラスサイズの合計に基づき設定される。

オブジェクトプロファイリングを行わない場合（ステップ１６０６の結果が「ＮＯ」）、又は、ステップ１６０５の処理の終了後には、オブジェクトIDフィールド７０２を含まない、通常オブジェクトをオブジェクト生成先に生成する（ステップ１６０８）。

ステップ１６０８の処理の終了後、又は、ステップ１６０９の処理の終了後には、オブジェクト生成処理の実行元に生成したオブジェクトを通知する（ステップ１６１０）。
ステップ１６１０の処理の終了後、又は、ステップ１６１１の処理の終了後には、本処理を終了する。

なお、オブジェクト生成先やオブジェクトプロファイリングを行うか否かに応じた専用のオブジェクト生成命令と、それに対するオブジェクト生成処理を用意し、バイトコード情報１１２のオブジェクト生成命令を適宜書き換えることで、所定のオブジェクト生成処理を実行するようにしてもよい。その場合、例えば、ステップ１６０４やステップ１６０７の判定が不要になることもある。

図１７は、本発明の実施の形態のGC処理１６０２の手順を示すフローチャートである。本処理は、プロセッサ１２９がGC部１２２を処理することによって、実行される。
プロセッサ１２９がGC部１２２を実行すると、GC部１２２は、まず、オブジェクト生成処理１５０２で枯渇している領域がJavaヒープ領域１１５のNew領域とOld領域のどちらかを判定する（ステップ１７０１）。

オブジェクト生成処理１５０２で枯渇している領域がJavaヒープ領域１１５のNew領域である場合には（ステップ１７０１の結果が「New領域」）、CopyGC部１２４を実行し、CopyGC処理を実行する（ステップ１７０２）。

オブジェクト生成処理１５０２で枯渇している領域がJavaヒープ領域１１５のOld領域である場合には（ステップ１７０１の結果が「Old領域」）、FullGC部１２３を実行し、FullGC処理を実行する（ステップ１７０３）。
ステップ１７０２の処理の終了後、又は、ステップ１７０３の処理の終了後には、本処理を終了する。

図１８は、本発明の実施の形態のFullGC処理１７０３の手順を示すフローチャートである。本処理は、プロセッサ１２９がFullGC部１２３を処理することによって、実行される。

プロセッサ１２９がFullGC部１２３を実行すると、FullGC部１２３は、まず、FullGC対象の全オブジェクトに対して、オブジェクトヘッダ７０１にオブジェクト種別“未解析”を設定する。また、以降のプログラムの実行に必要なオブジェクトであることを示すために、レジスタ、実行時スタック、グローバル変数といったルートセットからオブジェクト参照を順次辿ることによって到達可能なオブジェクトに対して、オブジェクトヘッダ７０１にオブジェクト種別“必要”を設定する。そして、ルートセットから到達可能なオブジェクトを全て辿った後で、オブジェクトヘッダ７０１のオブジェクト種別が“必要”であるオブジェクトを以降のプログラムの実行に必要なオブジェクト、オブジェクトヘッダ７０１のオブジェクト種別が“未解析”であるオブジェクトを以降のプログラムの実行に不要なオブジェクトとして、オブジェクトの必要・不要を判定する（ステップ１８０１）。

図１０は、本発明の実施の形態のFullGC処理１７０３のステップ１８０１の処理の終了時点におけるJavaヒープ領域１１５のOld領域に格納されたオブジェクトの状態を示す図である。

各ノードはオブジェクトを示している。二重丸で示すオブジェクトは、FullGC処理１７０３のステップ１８０１の処理によってオブジェクトヘッダ７０１にオブジェクト種別“必要”が設定されたオブジェクトである。なお、ノード内の記号はクラス名、クラス名の右下の数字はオブジェクトIDフィールド７０２に格納されたオブジェクトIDを示している。

また、オブジェクトを連結する矢印は、オブジェクトの参照関係を示している。実線の矢印は、FullGC処理１７０３のステップ１８０１の処理によって辿られたオブジェクト参照であり、破線の矢印は、オブジェクト参照は存在するが、FullGC処理１７０３のステップ１８０１の処理によって辿られることのなかったオブジェクト参照を示している。

ルートセット１００１は、レジスタ、実行時スタック、グローバル変数などである。ルートセット１００１に保持されるオブジェクト参照を起点としてFullGC処理１７０３のステップ１８０１の処理が実行されると、ルートセット１００１からオブジェクト参照を順次辿ることによって到達可能なオブジェクトは全て必要オブジェクトと判定される。したがって、図１０に示すように、オブジェクト１００２、オブジェクト１００３、オブジェクト１００４、オブジェクト１００５などの二重丸で示すオブジェクトは必要オブジェクトである。一方、ルートセット１００１からオブジェクト参照を順次辿ることによって到達することのできなかったオブジェクトは全て未解析オブジェクト（不要オブジェクト）と判定される。したがって、図１０に示すように、オブジェクト１００６、オブジェクト１００７、オブジェクト１００８などの一重丸で示すオブジェクトは未解析オブジェクトである。これら未解析オブジェクトは、FullGC処理１７０３によって実際に解放されるオブジェクトであるが、Javaヒープ１１５のOld領域の使用量を抑え、FullGC処理１７０３の発生を抑止するためには、外部ヒープ領域１１６に格納し、GCによらず解放することが望ましい。

また、未解析オブジェクトの参照関係において参照関係のルートに当たるオブジェクト１００６、オブジェクト１００７、オブジェクト１００８などの起点オブジェクトは、これらオブジェクトがルートセット１００１や必要オブジェクトから参照されなくなったことによって、起点オブジェクトからオブジェクトを順次辿ることによってのみ到達可能なオブジェクトも一緒に解放される。そのため、起点オブジェクトを含め、起点オブジェクトからオブジェクトを順次辿ることによって到達可能なオブジェクトを外部ヒープ領域１１６に格納するようにすれば、Javaヒープ１１５のOld使用量をより多く抑えることができる。そのためには、起点オブジェクトを特定し、それら起点オブジェクトを外部ヒープ領域１１６に生成するようにする必要がある。この起点オブジェクトの特定方法については、図１１で説明する。

ここで、図１８のFullGC処理１７０３のフローチャートの説明に戻る。
ステップ１８０１の処理の終了後には、JavaVM１１０の設定フラグを参照し、オブジェクトプロファイリングを行うか否かを判定する（ステップ１８０２）。

オブジェクトプロファイリングを行う場合には（ステップ１８０２の結果が「ＹＥＳ」）、オブジェクト解析部１２５を実行し、オブジェクトプロファイリング処理を実行する（ステップ１８０３）。

オブジェクトプロファイリングを行わない場合（ステップ１８０２の結果が「ＮＯ」）、又は、ステップ１８０３の処理の終了後には、オブジェクトヘッダ７０１のオブジェクト種別が“必要”でないオブジェクトを不要なオブジェクトとして解放する（ステップ１８０４）。
ステップ１８０４の処理の終了後には、本処理を終了する。

図１９は、本発明の実施の形態のオブジェクトプロファイリング処理１８０３の手順を示すフローチャートである。本処理は、プロセッサ１２９がオブジェクト解析部１２５を処理することによって、実行される。
本処理のステップ１９０１からステップ１９０４までの処理を実行することによって、起点オブジェクトを特定することができる。

本処理を実行すると、まず、ステップ１８０１で不要なオブジェクトと判定された全オブジェクトについて、未処理の不要オブジェクトが存在するか否かを判定する（ステップ１９０１）。

未処理の不要オブジェクトが存在する場合には（ステップ１９０１の結果が「ＹＥＳ」）、当該オブジェクトのオブジェクトヘッダ７０１のオブジェクト種別を参照し、オブジェクト種別が“未解析”であるか否かを判定する（ステップ１９０２）。

オブジェクト種別が“未解析”である場合には（ステップ１９０２の結果が「ＹＥＳ」）、当該オブジェクトのオブジェクトヘッダ７０１のオブジェクト種別を“起点”に設定する（ステップ１９０３）。

ステップ１９０３の処理の終了後には、ステップ１９０３の起点オブジェクトに対して、メンバオブジェクト処理を呼び出し、メンバオブジェクト処理を実行する（ステップ１９０４）。

オブジェクト種別が“未解析”でない場合（ステップ１９０２の結果が「ＮＯ」）、又は、ステップ１９０４の処理の終了後には、ステップ１９０１の処理に戻る。そして、未処理の不要オブジェクトに対して、本処理の実行を継続する。

未処理の不要オブジェクトが存在しない場合には（ステップ１９０１の結果が「ＮＯ」）、オブジェクトヘッダ７０１のオブジェクト種別が“起点”である起点オブジェクトについて、当該起点オブジェクトのオブジェクトIDフィールド７０２を参照し、当該起点オブジェクトのオブジェクトIDを取得する。そして、当該オブジェクトIDに係るオブジェクトプロファイリング回数５０３の値に１を加算して、オブジェクトプロファイリング情報テーブル３０２を更新する。また、当該オブジェクトIDに係るメンバオブジェクト情報アドレス５０４に格納してあるポインタにより当該起点オブジェクトに係るメンバオブジェクト情報３０３を参照する。なお、当該起点オブジェクトに係るメンバオブジェクト情報３０３が存在しない場合には、当該起点オブジェクトに係るメンバオブジェクト情報３０３を生成する。そして、当該起点オブジェクトと当該起点オブジェクトからオブジェクト参照を順次辿ることによって到達可能なメンバオブジェクトの参照関係に応じて、メンバオブジェクトデータ構造を当該メンバオブジェクト情報３０３に適宜追加し、該当するメンバオブジェクトデータ構造に格納されている、メンバオブジェクトプロファイリング回数に１を加算して、メンバオブジェクト情報３０３を更新する（ステップ１９０５）。
ステップ１９０５の処理の終了後には、本処理を終了する。

図２０は、本発明の実施の形態のメンバオブジェクト処理１９０４の手順を示すフローチャートである。本処理は、オブジェクトプロファイリング処理１８０３から呼び出されることやメンバオブジェクト処理１９０４から再帰的に呼び出されることによって、実行される。

本処理を実行すると、まず、本処理の処理対象となったオブジェクトについて、未処理の参照先オブジェクトが存在するか否かを判定する（ステップ２００１）。
未処理の参照先オブジェクトが存在する場合には（ステップ２００１の結果が「ＹＥＳ」）、参照先オブジェクトのオブジェクトヘッダ７０１のオブジェクト種別を参照し、オブジェクト種別を判定する（ステップ２００２）。

オブジェクト種別が“起点”である場合には（ステップ２００２の結果が「起点」）、参照先オブジェクトがメンバオブジェクト処理１８０３の呼び出し元の起点オブジェクトと同じであるか否かを判定する（ステップ２００３）。
参照先オブジェクトがメンバオブジェクト処理１８０３の呼び出し元の起点オブジェクトと同じでない場合には（ステップ２００３の結果が「ＮＯ」）、参照先オブジェクトのオブジェクトヘッダ７０１のオブジェクト種別を“メンバ”に設定する（ステップ２００５）。

オブジェクト種別が“未解析”である場合には（ステップ２００２の結果が「未解析」）、参照先オブジェクトのオブジェクトヘッダ７０１のオブジェクト種別を“メンバ”に設定する（ステップ２００４）。
ステップ２００４の処理の終了後には、当該参照先オブジェクトに対して、メンバオブジェクト処理１９０４を実行する（ステップ１９０４）。

オブジェクト種別が“メンバ”である場合（ステップ２００２の結果が「メンバ」）、参照先オブジェクトがメンバオブジェクト処理１８０３の呼び出し元の起点オブジェクトと同じである場合（ステップ２００３の結果が「ＹＥＳ」）、ステップ２００５の処理の終了後、又は、ステップ２００４の後に実行するステップ１９０４の処理の終了後には、ステップ２００１の処理に戻る。そして、未処理の参照先オブジェクトに対して（ステップ２００１の結果が「ＹＥＳ」）、本処理の実行を継続する。
未処理の参照先オブジェクトが存在しない場合には（ステップ２００１の結果が「ＮＯ」）、本処理を終了する。

図１１は、本発明の実施の形態のオブジェクトプロファイリング処理１８０３のステップ１９０１からステップ１９０４までの処理を実行することによって、起点オブジェクトを特定する具体的な手順を示す図である。

各ノードはオブジェクトを示している。細線の一重丸で示すオブジェクトは、FullGC処理１７０３のステップ１８０１の処理によってオブジェクトヘッダ７０１にオブジェクト種別“未解析”が設定されたままの不要オブジェクトである。なお、ノード内の記号はクラス名、クラス名の右下の数字はオブジェクトIDフィールド７０２に格納されたオブジェクトIDを示している。

また、オブジェクトを連結する矢印は、オブジェクトの参照関係を示している。実線の矢印は、オブジェクトプロファイリング処理１８０３のステップ１９０１からステップ１９０４までの処理を実行することによって辿られたオブジェクト参照であり、破線の矢印は、オブジェクト参照は存在するが、オブジェクトプロファイリング処理１８０３のステップ１９０１からステップ１９０４までの処理を実行することによってまだ辿られていないオブジェクト参照を示している。

図１１(a)は、FullGC処理１７０３のステップ１８０１の処理の終了時点の状態を示している。なお、オブジェクトの参照関係が判明していない状態から、オブジェクト１００９、オブジェクト１０１１、オブジェクト１００８、オブジェクト１０１０、オブジェクト１０１２の順にオブジェクトを処理していくものとする。

図１１(b)は、オブジェクト１００９を処理し、オブジェクトプロファイリング処理１８０３のステップ１９０２の判定においてオブジェクト種別が“未解析”であるため、オブジェクト１００９のオブジェクトヘッダ７０１のオブジェクト種別を“起点”に設定した状態を示している。その結果、起点オブジェクトであるオブジェクト１００９は太線の一重丸で示す。

図１１(c)は、オブジェクト１００９の参照先であるオブジェクト１０１１を処理し、メンバオブジェクト処理１９０４のステップ２００２の判定においてオブジェクト種別が“未解析”であるため、オブジェクト１０１１のオブジェクトヘッダ７０１のオブジェクト種別を“メンバ”に設定した状態を示す。その結果、メンバオブジェクトであるオブジェクト１０１１は×を付した一重丸で示す。オブジェクト１０１１の参照先オブジェクトは存在しないため、オブジェクト１００９の処理はここで終了となる。
また、オブジェクト１０１１を処理し、オブジェクトプロファイリング処理１８０３のステップ１９０２の判定においてオブジェクト種別が“未解析”でないため、オブジェクト１０１１の処理はここで終了となる。

図１１(d)は、オブジェクト１００８を処理し、オブジェクトプロファイリング処理１８０３のステップ１９０２の判定においてオブジェクト種別が“未解析”であるため、オブジェクト１００８のオブジェクトヘッダ７０１のオブジェクト種別を“起点”に設定した状態を示している。

図１１(e)は、オブジェクト１００８の参照先であるオブジェクト１００９を処理し、メンバオブジェクト処理１９０４のステップ２００２の判定においてオブジェクト種別が“起点”であり、メンバオブジェクト処理１９０４のステップ２００３の判定において、参照先であるオブジェクト１００９と呼び出し元のオブジェクト１００８は同じでないため、参照先であるオブジェクト１００９のオブジェクトヘッダ７０１のオブジェクト種別を“メンバ”に設定した状態を示している。
また、オブジェクト１００８の参照先であるオブジェクト１０１０を処理し、メンバオブジェクト処理１９０４のステップ２００２の判定においてオブジェクト種別が“未解析”であるため、参照先であるオブジェクト１０１０のオブジェクトヘッダ７０１のオブジェクト種別を“メンバ”に設定した状態を示している。さらに、オブジェクト１０１０の参照先であるオブジェクト１０１２を処理し、メンバオブジェクト処理１９０４のステップ２００２の判定においてオブジェクト種別が“未解析”であるため、参照先であるオブジェクト１０１２のオブジェクトヘッダ７０１にオブジェクト種別“メンバ”を設定した状態を示している。なお、オブジェクト１０１２の参照先であるオブジェクト１００８は、メンバオブジェクト処理１９０４のステップ２００２の判定においてオブジェクト種別が“起点”であり、メンバオブジェクト処理１９０４のステップ２００３の判定において、呼び出し元のオブジェクト１００８と同じであるため、オブジェクト１００８の処理はここで終了となる。
さらに、オブジェクト１０１０を処理し、オブジェクトプロファイリング処理１８０３のステップ１９０２の判定においてオブジェクト種別が“未解析”でないため、オブジェクト１０１０の処理はここで終了となる。オブジェクト１０１２についても同様である。

図１１(f)は、オブジェクト１００９、オブジェクト１０１１、オブジェクト１００８、オブジェクト１０１０、オブジェクト１０１２の処理が全て終了した状態を示しており、このオブジェクトの参照関係の解析により、オブジェクト１００８が起点オブジェクトであると特定することができる。また、オブジェクト１００９、オブジェクト１０１１、オブジェクト１０１０、及び、オブジェクト１０１２はメンバオブジェクトであり、メンバオブジェクトから起点オブジェクトへのオブジェクト参照１０１３は、存在しないものとして処理する。

図２１は、本発明の実施の形態のCopyGC処理１７０２の手順を示すフローチャートである。本処理は、プロセッサ１２９がCopyGC部１２４を処理することによって、実行される。

プロセッサ１２９がCopyGC部１２４を実行すると、CopyGC部１２４は、まず、New領域に格納してある以降のプログラム実行に必要なオブジェクトをNew領域内の別の領域に順次移動させ、移動されることのなかったオブジェクトを不要なオブジェクトとして解放する（ステップ２１０１）。なお、ステップ２１０１の処理において、外部ヒープ領域１１６に格納されている起点オブジェクトからオブジェクト参照を順次辿ることによって到達可能なオブジェクトについては、起点オブジェクトに対して、メンバオブジェクト移動処理を呼び出し、メンバオブジェクト移動処理を実行することで、適切な移動先に移動させる。メンバオブジェクト移動処理の詳細は、図２２で説明する。

ステップ２１０１の処理の終了後には、例えば、外部ヒープ１１７へのオブジェクト参照を検査し、どこからも参照されていない不要な外部ヒープ１１７が存在するか否かを判定する（ステップ２１０２）。
不要な外部ヒープ１１７が存在する場合には（ステップ２１０２の結果が「ＹＥＳ」）、不要な外部ヒープ領域１１６、例えば、外部ヒープ１や外部ヒープ３を解放することで、外部ヒープ１や外部ヒープ３に格納してある不要なオブジェクトを解放する（ステップ２１０３）。

不要な外部ヒープ１１７が存在しない場合（ステップ２１０２の結果が「ＮＯ」）、又は、ステップ２１０３の処理の終了後には、JavaVM１１０の設定フラグを参照し、CopyGC処理時にオブジェクト生成命令のオブジェクト生成先を変更するか否かを判定する（ステップ２１０４）。
オブジェクト生成先を変更する場合には（ステップ２１０４の結果が「ＹＥＳ」）、オブジェクト生成情報テーブル３０１に対して、オブジェクト生成先変更部１１３を実行し、オブジェクト生成先変更処理を実行する（ステップ１３０３）。
オブジェクト生成先を変更しない場合（ステップ２１０４の結果が「ＮＯ」）、又は、ステップ１３０３の処理の終了後には、本処理を終了する。

なお、本発明の実施の形態では、CopyGC処理時に不要な外部ヒープの解放とオブジェクト生成命令のオブジェクト生成先の変更を実施しているが、CopyGC処理時以外の所定のタイミングでこれらの処理を実施してもよい。

図２２は、本発明の実施の形態のメンバオブジェクト移動処理の手順を示すフローチャートである。本処理は、CopyGC処理１７０２のステップ２１０１の処理において、実行される。

本処理を実行すると、まず、本処理の処理対象となったオブジェクトについて、未処理の参照先オブジェクトが存在するか否かを判定する（ステップ２２０１）。
未処理の参照先オブジェクトが存在する場合には（ステップ２２０１の結果が「ＹＥＳ」）、参照先オブジェクトがCopyGC処理１７０２のステップ２１０１の処理によるNew領域からOld領域への移動対象であるか否かを判定する（ステップ２２０２）。なお、参照先オブジェクトがCopyGC処理によるNew領域からOld領域への移動対象であるとは、少なくともその参照先オブジェクトがOld領域に移動するのに十分な回数のCopyGCを経ている長命なオブジェクトであることを意味する。

参照先オブジェクトがNew領域からOld領域への移動対象である場合には（ステップ２２０２の結果が「ＹＥＳ」）、参照先オブジェクトのメンバオブジェクト適合率が、JavaVM１１０の設定閾値（第３の閾値）以上であるか否かを判定する（ステップ２２０３）。なお、この判定では、メンバオブジェクトのクラスサイズなどに応じて、メンバオブジェクト適合率に重み付けを行ってもよい。

参照先オブジェクトのメンバオブジェクト適合率が、設定閾値以上である場合には（ステップ２２０３の結果が「ＹＥＳ」）、参照先オブジェクトを起点オブジェクトと同じ外部ヒープに移動する（ステップ２２０４）。

図１２は、本発明の実施の形態のメンバオブジェクト移動処理の(a)開始時点、及び、(b)終了時点における外部ヒープ１、外部ヒープ２、及び、Javaヒープ１１５のNew領域とOld領域に格納されたオブジェクトの状態を示す図である。
各ノードはオブジェクトを示している。なお、ノード内の記号はクラス名の略称を示している。例えば、ノード内の記号が“A”であるオブジェクト１２０１のクラス名は“ClassA”になる。また、オブジェクトを連結する矢印は、オブジェクトの参照関係を示している。

ここで、オブジェクト１２０１は、外部ヒープ１に格納された起点オブジェクトである。また、オブジェクト１２０８は、外部ヒープ２に格納された起点オブジェクトである。オブジェクト１２０１が格納された外部ヒープ１の外部ヒープヘッダ９０１には、オブジェクト１２０１に係るメンバオブジェクト情報３０３へのポインタが格納してあり、このポインタによりオブジェクト１２０１に係るメンバオブジェクト情報３０３を参照する。同様に、オブジェクト１２０８が格納された外部ヒープ２の外部ヒープヘッダ９０１には、オブジェクト１２０８に係るメンバオブジェクト情報３０３へのポインタが格納してあり、このポインタによりオブジェクト１２０８に係るメンバオブジェクト情報３０３を参照する。なお、ここでは、オブジェクト１２０１に係るメンバオブジェクト情報３０３は図６に示してあるメンバオブジェクト情報３０３であるものとする。このメンバオブジェクト情報３０３の起点オブジェクトデータ構造６０１を参照して、ClassAの起点オブジェクトはFullGCによってOld領域で４回解放されたことがわかる。また、メンバオブジェクト情報３０３のメンバオブジェクトデータ構造６０６を参照して、ClassAの起点オブジェクトがFullGCによって解放されたことによってClassFのメンバオブジェクトがOld領域で３回解放されたこと、メンバオブジェクト情報３０３のメンバオブジェクトデータ構造６０５を参照して、ClassAの起点オブジェクトがFullGCによって解放されたことによってClassEのメンバオブジェクトがOld領域で２回解放されたことなどがわかる。

ここで、ClassB、ClassC、ClassD、ClassE、ClassF、及び、ClassGのメンバオブジェクト適合率は、それぞれ、1.00、1.00、1.00、0.50、0.75、0.25である。メンバオブジェクト適合率が高いメンバオブジェクトは、起点オブジェクトが不要になると同時に不要になる可能性が高いので、メンバオブジェクト適合率が高いメンバオブジェクトを起点オブジェクトと同じ外部ヒープに格納するようにすることによって、起点オブジェクトが不要になると同時に、その外部ヒープを解放することによって、メンバオブジェクト適合率が高いメンバオブジェクトを解放できる可能性も高くなる。そのため、メンバオブジェクト移動処理では、メンバオブジェクト適合率の高いメンバオブジェクトを起点オブジェクトと同じ外部ヒープに移動するようにする。例えば、メンバオブジェクト適合率の設定閾値が0.60の場合、メンバオブジェクト適合率が0.60以上であるオブジェクト１２０２、オブジェクト１２０３、オブジェクト１２０４、及び、オブジェクト１２０６は、メンバオブジェクト移動処理によって、オブジェクト１２０１と同じ外部ヒープ１に移動する。一方、メンバオブジェクト適合率が0.60以上でないオブジェクト１２０５は、メンバオブジェクト移動処理によって、ステップ２２０３の結果が「ＹＥＳ」となる別の起点オブジェクトであるオブジェクト１２０８と同じ外部ヒープ２に移動する。また、オブジェクト１２０７は、外部ヒープ領域１１６に格納された起点オブジェクトからオブジェクト参照を順次辿ることによって到達可能なオブジェクトであるが、メンバオブジェクト適合率が0.60以上ではないので、Javaヒープ領域１１５のOld領域に移動する。

ここで、図２２のメンバオブジェクト移動処理のフローチャートの説明に戻る。
ステップ２２０４の処理の終了後には、参照先オブジェクトに対して、メンバオブジェクト移動処理を呼び出し、メンバオブジェクト移動処理を実行する（ステップ２２０５）。

参照先オブジェクトがNew領域からOld領域への移動対象でない場合（ステップ２２０２の結果が「ＮＯ」）、参照先オブジェクトのメンバオブジェクト適合率が、設定閾値以上でない場合（ステップ２２０３の結果が「ＮＯ」）、及び、ステップ２２０５の処理の終了後には、ステップ２２０１の処理に戻る。そして、未処理の参照先オブジェクトに対して、本処理の実行を継続する。
未処理の参照先オブジェクトが存在しない場合には（ステップ２２０１の結果が「ＮＯ」）、本処理を終了する。

なお、このメンバオブジェクト移動処理において、ステップ２２０２の処理は省略してもよい。つまり、参照先オブジェクト（メンバオブジェクト）を起点オブジェクトが存在する外部ヒープと同じ外部ヒープに移動するか否かの判断は、ステップ２２０３の判定だけで行ってもよい。換言すれば、場合によっては、参照先オブジェクトがOld領域へ移るほど長命でなくても、参照先オブジェクトを起点オブジェクトと同じ外部ヒープに移動するように処理してGCの発生を抑えるほうが好都合である。ただ、一概にはいえないが、図２２の処理のように、ステップ２２０２の判定を設けて、より長命な参照先オブジェクトを起点オブジェクトと同じ外部ヒープに移動することは効果的である。

本発明の実施の形態では、例えば図２３のネットワーク構成に示すように、複数の計算機システム１０１とウェブサーバ２０１とがネットワーク２０３を介して通信可能に接続している。計算機システム１０１は、Javaソースファイル１０４の記述内容に従って機能するJavaアプリケーション１３２を有しており、JavaVM１１０がJavaアプリケーション１３２を実行することで所定のサービスを実現する。

一方、ウェブサーバ２０１は、入力装置、出力装置、プロセッサ、記憶装置といったハードウェア資源を有するコンピュータである。このウェブサーバ２０１は、例えばJavaサーブレット２０２を有している。ウェブサーバ２０１は、Javaサーブレット２０２を機能させることにより、動的にウェブページを生成し、そのウェブページをリクエストのあった計算機システム１０１に送信する。

なお、計算機システム１０１は、Javaアプリケーション１３２ではなく、Javaアプレットを有していてもよい。この場合、ウェブサーバ２０１が提供するウェブページを閲覧するウェブブラウザを用いてJavaアプレットを実行することで所定のサービスを実現する。
また、計算機システム１０１が有するJavaVM１１０は、予め出荷時に搭載されたものであってもよいし、ウェブサーバ２０１から取得したものであってもよい。

≪その他≫
前記した各実施形態は、本発明を実施するために好適のものであるが、その実施形式はこれらに限定されるものでなく、本発明の要旨を変更しない範囲内において種々変形することが可能である。

例えば、本実施形態で取り扱ったGCは、世代別GCであったが、本発明が適用可能なGCはこれに限らない。例えばパラレルGCに対しても適用可能である。

また、オブジェクトプロファイリング情報テーブル３０２において登録するオブジェクトプロファイリング回数５０３は、FullGCの回数でなく、CopyGCの回数であったり、他のGCの回数であったりしてもよい。

その他、ハードウェア、ソフトウェア、各フローチャート等の具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

１０１ 計算機システム（情報処理装置）
１０２ 補助記憶（記憶部）
１０３ Javaクラスファイル
１０４ Javaソースファイル
１０５ オブジェクト解析情報ファイル
１０６ 設定ファイル
１０７ 主記憶（記憶部）
１０８ データ領域
１０９ Javaコンパイラ
１１０ JavaVM
１１１ バイトコード読み込み部
１１２ バイトコード情報
１１３ オブジェクト生成先変更部
１１４ メソッド実行部
１１５ Javaヒープ領域（第１のメモリ領域）
１１６ 外部ヒープ領域（第２のメモリ領域）
１１７ 外部ヒープ１
１１８ 外部ヒープ２
１１９ 外部ヒープ３
１２０ メモリ管理部
１２１ オブジェクト生成部
１２２ GC部
１２３ FullGC部
１２４ CopyGC部
１２５ オブジェクト解析部
１２６ オブジェクト解析情報
１２７ オペレーティングシステム
１２８ バス
１２９ プロセッサ（制御部）
１３０ 入力装置
１３１ 出力装置
１３２ Javaアプリケーション
２０１ ウェブサーバ
２０２ Javaサーブレット
２０３ ネットワーク
３０１ オブジェクト生成情報テーブル
３０２ オブジェクトプロファイリング情報テーブル
３０３ メンバオブジェクト情報

Claims (13)

1. プログラムを実行するために確保したメモリ領域において、不要になったメモリ領域を自動的に解放する自動解放機能を有する仮想マシンが稼働する情報処理装置におけるメモリ管理方法であって、
   前記情報処理装置の記憶部は、
   前記メモリ領域として、前記自動解放機能の対象となる第１のメモリ領域と、
   前記メモリ領域として、前記自動解放機能の対象外となる第２のメモリ領域と、を有し、
   プログラムを実行するときに生成されるオブジェクトごとに、当該オブジェクトに係るオブジェクト生成命令と、前記オブジェクト生成命令により当該オブジェクトを前記第１のメモリ領域に生成した回数を示すオブジェクト生成回数と、前記自動解放機能により前記第１のメモリ領域を解放した回数を示すオブジェクトプロファイリング回数と、を含むオブジェクト解析情報を記憶しており、
   前記情報処理装置の制御部は、
   前記オブジェクト解析情報を参照して、前記オブジェクトのオブジェクト生成回数が、前記記憶部に記憶されている第１の閾値以上であるか否かを判定するステップと、
   前記オブジェクト生成回数が前記第１の閾値以上であるとき、前記オブジェクト生成回数に対する前記オブジェクトプロファイリング回数の割合が、前記記憶部に記憶されている第２の閾値以上であるか否かを判定するステップと、
   前記割合が前記第２の閾値以上であるとき、前記オブジェクト生成命令によるオブジェクトの生成先を前記第２のメモリ領域に変更するステップと、を実行する
   ことを特徴とするメモリ管理方法。
2. 前記情報処理装置の制御部は、
   前記第１のメモリ領域に生成されたオブジェクトのうち、前記仮想マシンが直接参照可能なオブジェクト、および前記直接参照可能なオブジェクトが直接的または間接的に参照するオブジェクトを除くオブジェクトを特定するステップと、
   前記オブジェクト解析情報を参照して、前記特定したオブジェクトのオブジェクト生成回数が前記第１の閾値以上であり、当該オブジェクト生成回数に対する前記オブジェクトプロファイリング回数の割合が前記第２の閾値以上であるとき、前記オブジェクト生成命令によるオブジェクトの生成先を前記第２のメモリ領域に変更するステップと、を実行する
   ことを特徴とする請求項１に記載のメモリ管理方法。
3. 前記情報処理装置の制御部は、
   前記特定したオブジェクトにおいて、前記仮想マシンから直接参照されず、並びにいずれのオブジェクトからも参照されないオブジェクトである起点オブジェクト、および前記起点オブジェクトが直接的または間接的に参照するオブジェクトであるメンバオブジェクトを設定するステップと、
   前記起点オブジェクトのオブジェクトプロファイリング回数に対する前記メンバオブジェクトのオブジェクトプロファイリング回数の割合が、前記記憶部に記憶されている第３の閾値以上であるか否かを判定するステップと、
   前記割合が前記第３の閾値以上であるとき、前記メンバオブジェクトも前記第２のメモリ領域に移動するステップと、を実行する
   ことを特徴とする請求項２に記載のメモリ管理方法。
4. 前記自動解放機能は、世代別ガベージコレクションによる自動解放機能であり、
   前記第１のメモリ領域は、長命でないオブジェクトが格納されるNew領域と、長命なオブジェクトが格納されるOld領域とを含んで構成される
   ことを特徴とする請求項１から請求項３のいずれか一項に記載のメモリ管理方法。
5. 前記オブジェクトプロファイリング回数が示す前記第１のメモリ領域の解放は、前記New領域および前記Old領域の両方を含む領域を対象にする解放である
   ことを特徴とする請求項４に記載のメモリ管理方法。
6. プログラムを実行するために確保したメモリ領域において、不要になったメモリ領域を自動的に解放する自動解放機能を有する仮想マシンが稼働する情報処理装置として機能させるメモリ管理プログラムであって、
   前記情報処理装置の記憶部は、
   前記メモリ領域として、前記自動解放機能の対象となる第１のメモリ領域と、
   前記メモリ領域として、前記自動解放機能の対象外となる第２のメモリ領域と、を有し、
   プログラムを実行するときに生成されるオブジェクトごとに、当該オブジェクトに係るオブジェクト生成命令と、前記オブジェクト生成命令により当該オブジェクトを前記第１のメモリ領域に生成した回数を示すオブジェクト生成回数と、前記自動解放機能により前記第１のメモリ領域を解放した回数を示すオブジェクトプロファイリング回数と、を含むオブジェクト解析情報を記憶しており、
   前記メモリ管理プログラムは、前記情報処理装置の制御部に、
   前記オブジェクト解析情報を参照して、前記オブジェクトのオブジェクト生成回数が、前記記憶部に記憶されている第１の閾値以上であるか否かを判定する処理と、
   前記オブジェクト生成回数が前記第１の閾値以上であるとき、前記オブジェクト生成回数に対する前記オブジェクトプロファイリング回数の割合が、前記記憶部に記憶されている第２の閾値以上であるか否かを判定する処理と、
   前記割合が前記第２の閾値以上であるとき、前記オブジェクト生成命令によるオブジェクトの生成先を前記第２のメモリ領域に変更する処理と、を実行させる
   ことを特徴とするメモリ管理プログラム。
7. 前記情報処理装置の制御部に、
   前記第１のメモリ領域に生成されたオブジェクトのうち、前記仮想マシンが直接参照可能なオブジェクト、および前記直接参照可能なオブジェクトが直接的または間接的に参照するオブジェクトを除くオブジェクトを特定する処理と、
   前記オブジェクト解析情報を参照して、前記特定したオブジェクトのオブジェクト生成回数が前記第１の閾値以上であり、当該オブジェクト生成回数に対する前記オブジェクトプロファイリング回数の割合が前記第２の閾値以上であるとき、前記オブジェクト生成命令によるオブジェクトの生成先を前記第２のメモリ領域に変更する処理と、を実行させる
   ことを特徴とする請求項６に記載のメモリ管理プログラム。
8. 前記情報処理装置の制御部に、
   前記特定したオブジェクトにおいて、前記仮想マシンから直接参照されず、並びにいずれのオブジェクトからも参照されないオブジェクトである起点オブジェクト、および前記起点オブジェクトが直接的または間接的に参照するオブジェクトであるメンバオブジェクトを設定する処理と、
   前記起点オブジェクトのオブジェクトプロファイリング回数に対する前記メンバオブジェクトのオブジェクトプロファイリング回数の割合が、前記記憶部に記憶されている第３の閾値以上であるか否かを判定する処理と、
   前記割合が前記第３の閾値以上であるとき、前記メンバオブジェクトも前記第２のメモリ領域に移動する処理と、を実行させる
   ことを特徴とする請求項７に記載のメモリ管理プログラム。
9. プログラムを実行するために確保したメモリ領域において、不要になったメモリ領域を自動的に解放する自動解放機能を有する仮想マシンが稼働する情報処理装置であって、
   前記メモリ領域として、前記自動解放機能の対象となる第１のメモリ領域と、
   前記メモリ領域として、前記自動解放機能の対象外となる第２のメモリ領域と、を有し、
   プログラムを実行するときに生成されるオブジェクトごとに、当該オブジェクトに係るオブジェクト生成命令と、前記オブジェクト生成命令により当該オブジェクトを前記第１のメモリ領域に生成した回数を示すオブジェクト生成回数と、前記自動解放機能により前記第１のメモリ領域を解放した回数を示すオブジェクトプロファイリング回数と、を含むオブジェクト解析情報を記憶している記憶部と、
   前記オブジェクト解析情報を参照して、前記オブジェクトのオブジェクト生成回数が、前記記憶部に記憶されている第１の閾値以上であるか否かを判定する制御と、
   前記オブジェクト生成回数が前記第１の閾値以上であるとき、前記オブジェクト生成回数に対する前記オブジェクトプロファイリング回数の割合が、前記記憶部に記憶されている第２の閾値以上であるか否かを判定する制御と、
   前記割合が前記第２の閾値以上であるとき、前記オブジェクト生成命令によるオブジェクトの生成先を前記第２のメモリ領域に変更する制御と、を実行する制御部とを有する
   ことを特徴とする情報処理装置。
10. 前記情報処理装置の制御部は、
    前記第１のメモリ領域に生成されたオブジェクトのうち、前記仮想マシンが直接参照可能なオブジェクト、および前記直接参照可能なオブジェクトが直接的または間接的に参照するオブジェクトを除くオブジェクトを特定する制御と、
    前記オブジェクト解析情報を参照して、前記特定したオブジェクトのオブジェクト生成回数が前記第１の閾値以上であり、当該オブジェクト生成回数に対する前記オブジェクトプロファイリング回数の割合が前記第２の閾値以上であるとき、前記オブジェクト生成命令によるオブジェクトの生成先を前記第２のメモリ領域に変更する制御と、を実行する
    ことを特徴とする請求項９に記載の情報処理装置。
11. 前記情報処理装置の制御部は、
    前記特定したオブジェクトにおいて、前記仮想マシンから直接参照されず、並びにいずれのオブジェクトからも参照されないオブジェクトである起点オブジェクト、および前記起点オブジェクトが直接的または間接的に参照するオブジェクトであるメンバオブジェクトを設定する制御と、
    前記起点オブジェクトのオブジェクトプロファイリング回数に対する前記メンバオブジェクトのオブジェクトプロファイリング回数の割合が、前記記憶部に記憶されている第３の閾値以上であるか否かを判定する制御と、
    前記割合が前記第３の閾値以上であるとき、前記メンバオブジェクトも前記第２のメモリ領域に移動する制御と、を実行する
    ことを特徴とする請求項１０に記載の情報処理装置。
12. 前記自動解放機能は、世代別ガベージコレクションによる自動解放機能であり、
    前記第１のメモリ領域は、長命でないオブジェクトが格納されるNew領域と、長命なオブジェクトが格納されるOld領域とを含んで構成される
    ことを特徴とする請求項９から請求項１１のいずれか一項に記載の情報処理装置。
13. 前記オブジェクトプロファイリング回数が示す前記第１のメモリ領域の解放は、前記New領域および前記Old領域の両方を含む領域を対象にする解放である
    ことを特徴とする請求項１２に記載の情報処理装置。

Images