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

Abstract

【課題】アプリケーションプログラムの実行に対して高い堅牢性を備えるメモリ管理機構を含む情報処理システムを提供する。
【解決手段】プログラムを実行するプロセッサ及び実行されたプログラムによって生成されたオブジェクトを格納する第１の記憶領域及び第２の記憶領域を含む記憶部を備える計算機において、プログラムを実行することによって生成されたオブジェクトを第１の記憶領域に格納し、第１の記憶領域に格納されたオブジェクトがアクセスされた場合には、アクセスされたオブジェクトのアクセス情報を記録し、記録されたアクセス情報に基づいてメモリリークの可能性の高いリークオブジェクトを抽出し、抽出されたリークオブジェクトを第２の記憶領域に移動させる。
【選択図】図２

Description

本発明は、メモリ管理技術に関し、特に、言語処理システムにおいてメモリに記憶されているオブジェクトの管理に関する。

アプリケーションプログラムが期待する実行性能を示さない原因の一つにメモリリークがあげられる。メモリリークとは、アプリケーションプログラムがプログラム実行中に確保されたメモリ領域が不要になった後も、何らかの理由によって確保されたメモリが解放されないためにアプリケーションプログラムのメモリ使用量が増え続ける現象である。

また、メモリリークが進行すると、使用可能なメモリの空き領域は徐々に減少し、プログラム実行に必要な量のメモリ領域を確保できなくなる場合がある。プログラム実行に必要な量のメモリ領域を確保できなくなると、アプリケーションプログラムの実行、又はアプリケーションプログラムを含めたシステム全体が、異常終了してしまう。このように、メモリリークは、アプリケーションプログラムの堅牢性を低下させる原因の一つでもある。

不要になったメモリ領域が解放されない原因は、言語仕様の観点では、大きく二つに分けることができる。一つは、プログラマがメモリ領域の解放操作を明示的に指定する必要のあるプログラム言語（例えば、Ｃ言語）において、メモリ領域が適切に解放されていないことを原因とする。もう一つは、言語処理システムが使用されたメモリ領域を暗黙的に解放するプログラム言語（例えば、Ｊａｖａ言語（「Ｊａｖａ」は登録商標、以下同じ））において、メモリ領域が解放されないことを原因とする。

前者の言語で作成されたアプリケーションプログラムでは、メモリ領域の解放操作を怠った場合にメモリリークが発生する。また、アプリケーションプログラムの実行中に使用されているメモリ領域へのポインタが書き換えられた場合などにもメモリリークが発生することもある。

このようなメモリリークの発生を検出するための技術として、例えば、特許文献１に開示された技術が知られている。特許文献１に開示された技術では、メモリ領域を確保する場合に、ファイル名とライン番号に加え、当該メモリ領域が解放されているべきイベントを示す満了イベントと従属ポインタを含む割当情報をメモリ割当テーブルに記録する。そして、メモリリークを検査する場合に、満了イベント終了後も解放されていないメモリ領域を検出する。

後者の言語、例えばＪａｖａ言語で作成されたアプリケーションプログラムでは、ガベージコレクション（以下、「ＧＣ」）機構（非特許文献１参照）によって、不要になったメモリ領域（オブジェクト）を回収する。オブジェクトの回収とは、オブジェクトが記憶されていたメモリ領域を解放することである。

ＧＣ機構の一般的な方式であるマーク・スイープ方式では、参照関係にあるオブジェクトに対し、必要なオブジェクトであることを示す印をつけ、その後、印のついていないオブジェクトを不要なオブジェクトとして回収する。したがって、Ｊａｖａ言語ではプログラムでの明示的なメモリ領域の解放を必要としないため、プログラマがメモリ領域の解放操作を怠った場合でもメモリリークは発生しない。

しかし、マーク・スイープ方式では、ユーザにとって不要になったオブジェクトであっても、参照関係にあるオブジェクトは回収されない。そのため、参照関係がある場合には不要なオブジェクトであっても回収されず、メモリリークが発生することがある。メモリ領域を明示的に解放する必要がない言語の場合には、参照関係にあるオブジェクトから不要なオブジェクトを特定することは極めて困難である。

そこで、このようなメモリリークの発生箇所を検出する技術として、オブジェクトのメモリ使用量をクラスごとに集計及び調査し、メモリ使用量が増加傾向にあるクラスのオブジェクトをメモリリークの疑いのあるオブジェクト（以下、リークオブジェクト）として検出する技術が開示されている（特許文献２参照）。

特許文献２に開示された技術では、確保されたメモリ領域に対する警告時間と最大生存時間を管理し、警告時間を過ぎても解放されないメモリ領域の解放を利用者に促す。そして、最大生存時間を過ぎても解放されないメモリ領域は、メモリ管理機構によって解放される。
特開平９−２４４９４８号公報 特開２００２−１０８６９８号公報 Ｒｉｃｈａｒｄ Ｊｏｎｅｓ、他１名、「Ｇａｒｂａｇｅ Ｃｏｌｌｅｃｔｉｏｎ」、Ｊｏｈｎ Ｗｉｌｅｙ＆Ｓｏｎｓ、ｐ.２５−２８

ＧＣ機構によってメモリ領域が解放されるプログラム言語によって開発されたアプリケーションプログラムでは、特許文献１に開示された技術を適用することができず、参照関係にあるオブジェクトの中から不要なオブジェクトをオブジェクト単位で検出することが困難である。

また、参照関係にあるオブジェクトから不要なオブジェクトである可能性の高いオブジェクトを検出することは可能であるが、検出処理の実行負荷が大きいため、アプリケーションプログラムの実行性能を低下させるおそれがある。

一方、特許文献２に開示された従来技術では、最大生存時間を長く設定すると、メモリリークへの対応が遅れ、また、最大生存時間を短く設定すると、必要なオブジェクトを回収することがあるため、アプリケーションプログラムが正常に動作しないおそれがある。さらに、メモリリークが発生する状況では、不要なオブジェクトが大量に蓄積されているため、利用者にリークオブジェクトの回収を判断させると、利用者の負担が大きくなり、現実的ではない。

本発明では、メモリ管理機構を備える言語処理システムにおいて、アプリケーションプログラムの実行に対して高い堅牢性を備え、ＧＣ処理にともなう処理速度の低下を抑えることができるリークオブジェクトの検出技術を提供する。

本発明の代表的な一形態では、計算機において実行される情報処理システムのメモリ管理方法であって、前記計算機は、プログラムを実行するプロセッサ及び前記プロセッサによってアクセスされる記憶部を備え、前記記憶部は、前記プロセッサによって実行されたプログラムによって使用される記憶領域を管理するメモリ管理部、及び前記プログラムを実行することによって生成されたオブジェクトに対するアクセス情報を格納し、前記生成されたオブジェクトを格納する第１の記憶領域及び第２の記憶領域を含み、前記プロセッサは、前記生成されたオブジェクトを前記第１の記憶領域に格納し、前記第１の記憶領域に格納されたオブジェクトがアクセスされた場合には、前記アクセスされたオブジェクトの情報を前記アクセス情報に記録し、前記アクセス情報に基づいて、メモリリークの可能性の高いリークオブジェクトを抽出し、前記抽出されたリークオブジェクトを前記第２の記憶領域に移動させる。

本発明の一形態によれば、記憶領域（例えば、ヒープ領域）の使用効率を向上させることができる。

図１は、本発明の実施の形態のＪａｖａＶＭが動作する計算機システム１０１の構成及び入出力データを示す図である。

本発明の実施の形態の計算機システム１０１では、Ｊａｖａ言語によって記述されたプログラムがコンパイルされることによって、Ｊａｖａクラスファイルが作成される。さらに、Ｊａｖａクラスファイルが実行されることによって所定の業務処理が実行される。

計算機システム１０１は、プロセッサ１３１、主記憶１０７、補助記憶１０２、出力装置１３０、及び入力装置１３２を含む。プロセッサ１３１、主記憶１０７、補助記憶１０２、出力装置１３０、及び入力装置１３２は、バス１２９を介して互いに接続される。

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

補助記憶１０２は、業務処理の実行に使用されるＪａｖａクラスファイル１０３、Ｊａｖａクラスファイルを生成するためのＪａｖａソースファイル１０４、処理に使用されるファイル１０５、及びＪａｖａＶＭ１０９の設定ファイル１０６を含む。

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

ここで、主記憶１０７に記憶されるＪａｖａＶＭ１０９について説明する。ＪａｖａＶＭ１０９は、不要になったメモリ領域を自動的に回収するメモリ管理機構を備える言語処理システムである。

ＪａｖａＶＭ１０９は、メソッド読み取り部１１３、動的コンパイラ部１１６、メモリ管理部１２４、及びメソッド実行部１２３を含む。メソッド読み取り部１１３、動的コンパイラ部１１６、メモリ管理部１２４、及びメソッド実行部１２３は、プロセッサ１３１によって実行されるプログラムである。また、ＪａｖａＶＭ１０９は、コンパイルコード格納領域１１７、Ｊａｖａヒープ領域１２２、及び外部ヒープ領域１１０を含む。

メソッド読み取り部１１３は、プロセッサ１３１によって実行されることによって、Ｊａｖａクラスファイル１０３からメソッドを読み込み、メソッド情報１１８を作成する。動的コンパイラ部１１６は、プロセッサ１３１によって実行されることによって、メソッド情報１１８に基づいて、メソッドを動的にコンパイルする。

メモリ管理部１２４は、プロセッサ１３１によって実行されることによって、ＪａｖａＶＭ１０９で使用するメモリ領域を管理する。メモリ管理部１２４は、ページトラップ検出部１１１、インポート実行部１１４、ＧＣ実行部１１５、リークオブジェクト検出部１２０、及びメモリ確保部１２１を含む。各部の詳細については、図２にて後述する。

メソッド実行部１２３は、プロセッサ１３１によって実行されることによって、メソッドを実行する。メソッド実行部１２３は、コンパイルコード実行部１２６及びインタプリタ実行部１２７を含む。

コンパイルコード格納領域１１７は、動的コンパイラ部１１６による動的コンパイルの結果であるコンパイルコード１２５を格納する。Ｊａｖａヒープ領域１２２は、メソッド情報１１８及びオブジェクト１１９を格納する。外部ヒープ領域１１０は、リークオブジェクト１１２を格納する。Ｊａｖａヒープ領域１２２及び外部ヒープ領域１１０には、オブジェクトがポインタによって接続された木構造を構成されて格納されている。

Ｊａｖａソースファイル１０４は、Ｊａｖａコンパイラ１０８によって、インタプリタ実行部１２７が解釈及び実行可能な形式であるバイトコードにコンパイルされると、Ｊａｖａクラスファイル１０３が生成される。Ｊａｖａクラスファイル１０３は、ＪａｖａＶＭ１０９に入力されると、メソッド読み取り部１１３によって解析され、Ｊａｖａヒープ領域１２２にメソッド情報１１８が作成される。

プロセッサ１３１は、プログラムを実行する場合には、まず、インタプリタ実行部１２７がメソッド情報１１８を読み込み、メソッドをインタプリタ実行する。一方、インタプリタ実行において実行頻度が高いメソッドについては、動的コンパイラ部１１６がメソッド情報１１８を読み込み、動的にコンパイルし、コンパイルコード１２５をコンパイルコード格納領域１１７に作成する。そして、コンパイルコード実行部１２６がコンパイルコード１２５を読み込み、メソッドをコンパイルコード実行する。なお、ＪａｖａＶＭ１０９は、最初から最後までメソッドをインタプリタ実行してもよいし、最初からコンパイルコード実行してもよい。

図２は、本発明の実施の形態であるＪａｖａＶＭ１０９におけるメモリ管理部１２４の構成と入出力データを示す図である。

まず、メソッド実行部１２３によるメソッド実行処理の概要を簡単に説明すると、プロセッサ１３１は、実行する命令がメモリ確保命令の場合に、メモリ確保部１２１にＪａｖａヒープ領域１２２へのメモリ確保処理を要求する。

メモリ確保部１２１は、メソッド実行部１２３からメモリ確保処理要求を受け付けると、Ｊａｖａヒープ領域１２２へのメモリ確保を試みる。ここで、メモリ確保に成功した場合には、確保されたメモリ領域を呼び元に返却する。メモリ確保に失敗した場合には、ＧＣ実行部１１５を呼び出してＧＣ処理を実行し、Ｊａｖａヒープ領域１２２で不要になったメモリ領域を開放する。そして、再びメモリ確保を試み、さらに失敗した場合にはメモリ不足エラーを発生させる。

ここで、メモリ管理部１２４の各構成について概要を以下に説明する。

メモリ管理部１２４は、前述のように、ページトラップ検出部１１１、インポート実行部１１４、ＧＣ実行部１１５、リークオブジェクト検出部１２０、及びメモリ確保部１２１を含む。メモリ管理部１２４は、さらに、リークオブジェクト検出管理情報２０８、Ｊａｖａヒープ領域管理テーブル２１３、外部ヒープ領域管理テーブル２１４、ファイル管理テーブル２１５、外部ヒープ領域管理情報２１６、ファイルオフセットマップ２１７、及びインポート実行管理情報２１８を含む。

リークオブジェクト検出管理情報２０８は、リークオブジェクトを検出するための処理に必要な情報を格納する。リークオブジェクト検出管理情報２０８の詳細は、図３に後述する。

Ｊａｖａヒープ領域管理テーブル２１３は、Ｊａｖａヒープ領域１２２を特定する情報が格納される。Ｊａｖａヒープ領域管理テーブル２１３の詳細は、図４Ａにて後述する。外部ヒープ領域管理テーブル２１４は、外部ヒープ領域を特定する情報が格納される。外部ヒープ領域管理テーブル２１４の詳細は、図４Ｂにて後述する。

ファイル管理テーブル２１５は、外部ヒープ領域として使用されるファイル１０５を特定するファイルポインタを格納する。ファイル管理テーブル２１５の詳細は、図４Ｃにて後述する。

外部ヒープ領域管理情報２１６は、外部ヒープ領域１１０として使用する媒体に関する情報を格納する。外部ヒープ領域管理情報２１６の詳細は、図３にて後述する。

ファイルオフセットマップ２１７は、外部ヒープ領域として使用されるファイル１０５と論理記憶領域とを関連付けるために使用される。ファイルオフセットマップ２１７の詳細は、図９にて後述する。

インポート実行管理情報２１８は、Ｊａｖａヒープ領域１２２に格納されたオブジェクトを外部ヒープ領域１１０に移行する際に必要な情報を格納する。インポート実行管理情報２１８の詳細は、図３にて後述する。

また、本発明の実施の形態では、リークオブジェクト１１２の再配置先となる外部ヒープ領域１１０として、主記憶１０７以外のメモリ及びファイル１０５などを使用できる。ファイル１０５は、メモリマップを用いることによってメモリと同様に使用してもよいし、論理アドレス空間とファイルオフセットを対応付けるためのファイルオフセットマップ２１７を使用してメモリとは別に管理してもよい。

なお、本発明の実施の形態では、外部ヒープ領域１１０としてファイル１０５を使用し、ファイルオフセットマップ２１７を使用してメモリとは別に管理する。また、外部ヒープ領域１１０として使用される媒体に関する情報は、外部ヒープ領域管理情報２１６含まれる。

続いて、リークオブジェクト検出部１２０の構成について説明する。

リークオブジェクト検出部１２０は、リークオブジェクト検査部２０６及びリークオブジェクト判定部２０７を含む。リークオブジェクト検査部２０６は、Ｊａｖａヒープ領域１２２に記憶されているオブジェクトのアクセス状況を検査する。リークオブジェクト判定部２０７は、アクセスされていないオブジェクト（非アクセスオブジェクト）がリークオブジェクトであるか否かを判定する。

リークオブジェクト検査部２０６は、アクセス領域検査部２０１、アクセスアドレステーブル２０２、非アクセスオブジェクトアドレス収集部２０３、及び非アクセスオブジェクトアドレステーブル２０５を含む。

アクセス領域検査部２０１は、プロセッサ１３１によって実行されることによって、Ｊａｖａヒープ領域１２２に記憶された情報がアクセスされたか否かを領域ごとに検査する。アクセス領域検査部２０１の処理の詳細は、図１１にて後述する。

アクセスアドレステーブル２０２は、メソッドの実行などによってアクセスされた領域のアドレスが格納される。アクセスアドレステーブル２０２の詳細は、図５にて後述する。

非アクセスオブジェクトアドレス収集部２０３は、プロセッサ１３１によって実行されることによって、アクセスされていないオブジェクトのアドレスを収集する。非アクセスオブジェクトアドレス収集部２０３の処理の詳細は、図１２にて後述する。

非アクセスオブジェクトアドレステーブル２０５は、アクセスされていないオブジェクトのアドレスを格納する。非アクセスオブジェクトアドレステーブル２０５の詳細は、図６にて後述する。

ここで、リークオブジェクト検出部１２０の処理の概要について説明する。

オペレーティングシステム１２８は、ページトラップが発生したことを検知すると、その旨をページトラップ検出部１１１に通知する。

ページトラップ検出部１１１は、オペレーティングシステム１２８からページトラップが発生した旨を通知されると、通知内容に基づいて、アクセス領域検査部２０１又はインポート実行部１１４に処理要求を送信する。

アクセス領域検査部２０１は、ページトラップ検出部１１１から処理要求を受け付けると、アクセス領域検査処理を実行し、アクセスアドレステーブル２０２を更新する。

非アクセスオブジェクトアドレス収集部２０３は、非アクセスオブジェクトアドレス収集処理要求２０４を受け付けると、リークオブジェクト検出管理情報２０８に基づいて、非アクセスオブジェクトアドレス収集処理を実行し、非アクセスオブジェクトアドレステーブル２０５を更新する。

リークオブジェクト判定部２０７は、リークオブジェクト検出管理情報２０８に基づいて、非アクセスオブジェクトアドレステーブル２０５に登録されたオブジェクトがリークオブジェクトであるか否かを判定する。

インポート実行部１１４は、ページトラップ検出部１１１から処理要求を受け付けると、インポート実行管理情報２１８に基づいて、インポート処理を実行する。インポート処理では、アクセスされた外部ヒープ領域１１０に配置されたリークオブジェクト１１２をＪａｖａヒープ領域１２２に再配置する。外部ヒープ領域１１０としてファイル１０５が使用され、ファイルオフセットマップ２１７に基づいて主記憶と別に管理されている場合には、ファイルオフセットマップ２１７に基づいて、論理アドレス空間とファイルオフセットのマッピングを解決する。

ＧＣ実行部１１５は、不要になったオブジェクトを特定し、メモリ領域から解放する。ＧＣ実行部１１５は、オブジェクト種別判定部２０９、再配置アドレス計算部２１０、オブジェクト参照更新部２１１、及び再配置実行部２１２を含む。

オブジェクト種別判定部２０９は、Ｊａｖａヒープ領域１２２に記憶されたオブジェクトにオブジェクト種別を付与し、リークオブジェクト判定部２０７を実行することによって、当該オブジェクトがリークオブジェクトであるか否かを判定する。オブジェクト種別判定部２０９の処理の詳細は、図２１にて後述する。また、オブジェクト種別については、図８に示す。

再配置アドレス計算部２１０は、再配置対象のオブジェクトをオブジェクト種別に基づいて、再配置先のアドレスを計算する。再配置アドレス計算部２１０の処理の詳細は、図３０にて後述する。

オブジェクト参照更新部２１１は、再配置アドレス計算部２１０によって算出された再配置先アドレスで再配置対象のオブジェクトの参照情報を更新する。オブジェクト参照更新部２１１は、ＧＣ処理において実行される。

再配置実行部２１２は、再配置アドレス計算部２１０によって算出されたオブジェクトの再配置先アドレスに基づいて、対象のオブジェクトを再配置する。再配置実行部２１２の処理の詳細は、図３１にて後述する。

図３は、本発明の実施の形態のリークオブジェクト検出管理情報２０８、外部ヒープ領域管理情報２１６、及びインポート実行管理情報２１８の一例を示す図である。

リークオブジェクト検出管理情報２０８は、リークオブジェクトを検出するための処理に必要な項目を格納する。リークオブジェクト検出管理情報２０８は、リークオブジェクト検出実行フラグ３００１、リークオブジェクト検出実行条件３００２、リークオブジェクト検出領域ページ数３００３、アクセスアドレス収集回数３００４、リークオブジェクト条件３００５、及びオブジェクト整列実行フラグ３００６を含む。

リークオブジェクト検出実行フラグ３００１は、リークオブジェクト検出が実行中か否かを示す。リークオブジェクト検出実行フラグ３００１の値が“１”であればリークオブジェクト検出実行中であることを示し、“０”であればリークオブジェクト検出実行中でないことを示す。なお、ＪａｖａＶＭ起動時のリークオブジェクト検出実行フラグ３００１の初期値は、リークオブジェクト検出実行条件３００２の値によって決定される。

リークオブジェクト検出実行条件３００２は、リークオブジェクトの検出処理を実行する条件であるＪａｖａヒープ領域１２２のメモリ使用量を格納する。例えば、リークオブジェクト検出実行条件３００２の値が“２５６Ｍ”であれば、Ｊａｖａヒープ領域１２２のメモリ使用量が２５６ＭＢ以上の場合にリークオブジェクトの検出処理を実行し、メモリ使用量が２５６ＭＢを下回っている場合にはリークオブジェクトの検出処理を実行しない。また、リークオブジェクト検出実行条件３００２の値が“０以下”の場合には、リークオブジェクトの検出処理を常に実行するように設定することができる。リークオブジェクト検出実行条件３００２の値がＪａｖａヒープ領域１２２のサイズより大きい値の場合には、リークオブジェクトの検出処理を常に実行しないように設定することができる。

リークオブジェクト検出領域ページ数３００３は、リークオブジェクト検出領域３２０１の範囲をページ単位で格納する。リークオブジェクト検出領域３２０１は、リークオブジェクトの検出処理を実行する対象の領域である。リークオブジェクト検出領域３２０１の詳細は、図５にて後述する。例えば、リークオブジェクト検出領域ページ数３００３の値が“１６Ｋ”であれば、Ｊａｖａヒープ領域１２２の先頭から１６ＫＢのサイズのページがリークオブジェクト検出領域３２０１となる。ただし、リークオブジェクト検出領域ページ数３００３にＪａｖａヒープ領域１２２のメモリ使用量を超えるページ数が指定された場合には、Ｊａｖａヒープ領域１２２のメモリ使用量に基づいたページ数をリークオブジェクト検出領域ページ数３００３に格納する。

アクセスアドレス収集回数３００４は、アクセス領域検査部２０１によるアクセスアドレス収集処理において、リークオブジェクト検出領域３２０１の各ページに対するアクセスアドレス収集処理の実行回数の上限を保持する。例えば、アクセスアドレス収集回数３００４の値が“３”である場合、アクセスアドレス収集処理を３回実行したページのページトラップが解除される。

リークオブジェクト条件３００５は、リークオブジェクトの判定基準である非アクセスオブジェクトアドレステーブル２０５の非アクセス回数３３０２の閾値を示す。例えば、リークオブジェクト条件３００５の値が“５”である場合には、リークオブジェクト判定部２０７によって、非アクセスオブジェクトアドレステーブル２０５の非アクセス回数３３０２の値が５以上のオブジェクトがリークオブジェクトと判定される。

オブジェクト整列実行フラグ３００６は、再配置実行処理の場合に、オブジェクトのアクセス傾向に基づいてオブジェクトを整列するか否かを示す。オブジェクト整列実行フラグ３００６の値が“１”であればオブジェクトを整列し、“０”であればオブジェクトを整列しない。

外部ヒープ領域管理情報２１６は、外部ヒープ領域種別３００７を含む。外部ヒープ領域種別３００７は、外部ヒープ領域１１０の種別を示す。例えば、外部ヒープ領域種別３００７の値が“０”であれば、外部ヒープ領域１１０はメモリに確保される領域であることを表す。また、“１”であればファイル１０５に確保される領域であることを表し、ファイルオフセットマップ２１７によりメモリとは別に管理される。なお、本発明の実施の形態では、外部ヒープ領域１１０は、ファイル１０５に確保される領域であり、ファイルオフセットマップ２１７によってメモリとは別に管理される。

インポート実行管理情報２１８は、インポート範囲３００８及び参照解決フラグ３００９を含む。インポート処理は、インポート実行部１１４がプロセッサ１３１に処理されることによって実行される。インポート処理は、外部ヒープ領域１１０に格納されたオブジェクトをＪａｖａヒープ領域１２２に移動させる処理である。インポート処理の詳細は、図３３にて後述する。

インポート範囲３００８は、アクセスされたオブジェクトのオブジェクト参照を辿ることによって到達可能な他のリークオブジェクトを、外部ヒープ領域１１０からＪａｖａヒープ領域１２２に再配置する範囲を格納する。例えば、インポート範囲３００８の値が“２”である場合には、アクセスされたオブジェクトのオブジェクト参照を２段階辿ることによって到達可能なリークオブジェクトを外部ヒープ領域１１０からＪａｖａヒープ領域１２２に再配置する。また、インポート範囲３００８の値が“０”である場合には、直接アクセスされたオブジェクトだけをインポート処理の対象とすることができる。

さらに、インポート範囲３００８の値が負の数である場合には、直接アクセスされたオブジェクトであってもインポート処理の対象としないとすることができる。例えば、対象のオブジェクトのアクセス頻度が非常に少ない場合などには、Ｊａｖａヒープ領域１２２にオブジェクトを再配置しても、ＧＣ処理によって外部ヒープ領域１１０に当該オブジェクトが再配置される可能性が高い。このように、直接アクセスされたオブジェクトをインポート処理の対象としないことによって、インポート処理及びＧＣ処理によって生じるオーバーヘッドを削減することができる。

参照解決フラグ３００９は、外部ヒープ領域１１０に配置されたリークオブジェクト１１２のオブジェクト参照をＧＣ処理時に解決するか否かを示す。参照解決フラグ３００９の値が“１”であれば前述のオブジェクト参照をＧＣ処理において解決することを示し、“０”であればインポート処理において解決することを示している。

なお、オブジェクト参照をＧＣ処理において解決するのであれば、外部ヒープ領域１１０に再配置されたリークオブジェクト１１２は、ＧＣ処理におけるオブジェクト参照更新処理及びオブジェクト参照更新処理の対象となる。一方、オブジェクト参照をインポート処理において解決するのであれば、外部ヒープ領域１１０に再配置されたリークオブジェクトはＧＣ処理の対象外となる。なお、本発明の実施の形態では、リークオブジェクト１１２のオブジェクト参照をインポート処理において解決し、外部ヒープ領域１１０に配置されたオブジェクトはＧＣ処理の対象外とする。

リークオブジェクト検出管理情報２０８のリークオブジェクト検出実行フラグ３００１以外の各フィールドは、設定ファイル１０６又はＪａｖａＶＭ起動時の入力装置１３２からの入力によって利用者が指定することができる。

図４Ａは、本発明の実施の形態のＪａｖａヒープ領域１２２を管理するためのＪａｖａヒープ領域管理テーブル２１３の一例を示す図である。

Ｊａｖａヒープ領域管理テーブル２１３は、領域先頭３１０１、生存領域終端３１０２、検出領域終端３１０３、未使用領域先頭３１０４、及び領域終端３１０５を含む。

領域先頭３１０１は、Ｊａｖａヒープ領域１２２の先頭アドレスを格納する。領域終端３１０５は、Ｊａｖａヒープ領域１２２の終端アドレスを格納する。

生存領域終端３１０２は、生存オブジェクト配置領域１２０１の終端アドレスを格納する。なお、生存領域終端３１０２に格納されるアドレスは、アクセスオブジェクト配置領域１２０２の先頭アドレスと同じである。

検出領域終端３１０３は、リークオブジェクト検出管理情報２０８のリークオブジェクト検出領域ページ数３００３に基づいて設定されるリークオブジェクト検出領域の終端アドレスを格納する。

未使用領域先頭３１０４は、Ｊａｖａヒープ領域１２２の未使用領域の先頭アドレスを格納する。なお、未使用領域先頭３１０４が保持するアドレスは、アクセスオブジェクト配置領域１２０２の終端アドレスと同じである。

図４Ｂは、本発明の実施の形態の外部ヒープ領域１１０を管理するための外部ヒープ領域管理テーブル２１４の一例を示す図である。外部ヒープ領域管理テーブル２１４は、外部ヒープ領域１１０が主記憶１０７に確保された場合に使用される。

領域先頭３１０６は、外部ヒープ領域１１０の先頭アドレスを格納する。領域終端３１０８は、外部ヒープ領域１１０の終端アドレスを格納する。未使用領域先頭３１０７は、外部ヒープ領域１１０の未使用領域の先頭アドレスを格納する。

図４Ｃは、本発明の実施の形態の外部ヒープ領域１１０が補助記憶１０２に格納されたファイル１０５に確保される場合に使用されるファイル管理テーブル２１５の一例を示す図である。

ファイルポインタ３１０９は、ファイル１０５のファイルポインタを格納する。ファイルオフセット３１１０は、ファイル１０５のファイルオフセットを格納する。

ＪａｖａＶＭ１０９の実行性能を考慮すると、オブジェクトを物理アドレス空間に配置したほうが性能がよい。しかし、アクセス頻度が少ないためにメモリリークが発生した可能性が高いと判定されたオブジェクトを格納する外部ヒープ領域１１０では、論理アドレス空間を適用としても実行性能を著しく低下させることはない。本発明の実施の形態では、外部ヒープ領域１１０を物理アドレス空間及び論理アドレス空間のいずれにも確保することを可能とし、物理アドレス空間及び論理アドレス空間の両方を確保して運用することも可能である。

なお、本発明の実施の形態では、Ｊａｖａヒープ領域１２２を物理アドレス空間、外部ヒープ領域１１０を論理アドレス空間に確保し、外部ヒープ領域１１０に配置されるリークオブジェクト１１２の実体は、リークオブジェクト１１２の論理アドレスに対応するファイル１０５のオフセットの位置に記録する。論理アドレスとファイルオフセットのマッピングを保持するファイルオフセットマップ２１７については、図９にて後述する。

図５は、本発明の実施の形態のリークオブジェクト検出領域３２０１及びアクセスアドレステーブル２０２を示す図である。

リークオブジェクト検出領域３２０１は、前述のように、リークオブジェクトの検出処理を実行する対象の領域である。リークオブジェクト検出管理情報２０８のリークオブジェクト検出領域ページ数３００３に基づいて、Ｊａｖａヒープ領域１２２にページが設定される。

アクセスアドレステーブル２０２は、リークオブジェクト検出領域３２０１の各ページに対応するブロックを含む。各ブロックは、リークオブジェクト検出管理情報２０８のアクセスアドレス収集回数３００４に基づいた数のフィールドを有する。当該フィールドは、アクセスアドレス４０２を格納し、初期状態では未登録状態を表すＮＵＬＬ値が格納される。

図６は、本発明の実施の形態の非アクセスオブジェクトアドレステーブル２０５の一例を示す図である。

非アクセスオブジェクトアドレステーブル２０５は、非アクセスオブジェクトアドレス３３０１及び非アクセス回数３３０２を含む。

非アクセスオブジェクトアドレス３３０１は、非アクセスオブジェクト５０２のアドレスを格納する。非アクセス回数３３０２は、非アクセスオブジェクトアドレス３３０１によって特定される非アクセスオブジェクト５０２が非アクセスオブジェクトアドレス収集部２０３によって実行された非アクセスオブジェクトアドレス収集処理によって連続して収集された回数を格納する。非アクセス回数３３０２の値は大きいほど現在アクセスされない傾向にあることを示す。

なお、非アクセスオブジェクトアドレス３３０１の各フィールドは、オブジェクト参照更新部２１１によるオブジェクト参照更新処理の対象である。そのため、非アクセスオブジェクトアドレス３３０１によって特定されるオブジェクトがＧＣ処理によって再配置されると、非アクセスオブジェクトアドレス３３０１に格納されるアドレスも更新される。

図７は、本発明の実施の形態のオブジェクト構造を示す図である。オブジェクトは、オブジェクトヘッダ３４０１とオブジェクトデータ３４０２から構成される。

オブジェクトヘッダ３４０１は、オブジェクトの管理情報である。オブジェクトデータ３４０２は、オブジェクトのデータ本体である。

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

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

具体的には、オブジェクト種別ビット３５０１が“００”の場合には、不要なオブジェクトである“デッド”オブジェクトであることを示す。また、オブジェクト種別ビット３５０１が“１１”の場合には、メモリリークが発生している可能性が高いオブジェクトである”リーク”オブジェクトであることを示す。

さらに、オブジェクト種別ビット３５０１が“１０”の場合には、直近のメソッド実行中にアクセスされたことがアクセスアドレステーブル２０２に記録されたオブジェクトである“アクセス”オブジェクトであることを示す。オブジェクト種別ビット３５０１が“０１”の場合には、直近のメソッド実行ではアクセスされていないが、比較的最近にアクセスされた“生存”オブジェクトであることを示す。

図９は、本発明の実施の形態のファイルオフセットマップ２１７の一例を示す図である。ファイルオフセットマップ２１７は、オブジェクトアドレス３７０１及びファイルオフセット３７０２を含む。

オブジェクトアドレス３７０１は、外部ヒープ領域１１０に仮想的に配置されたオブジェクトの論理アドレスを格納する。ファイルオフセット３７０２は、オブジェクトアドレス３７０１が指し示すオブジェクトの実体が記録されたファイル１０５のファイルオフセットを保持する。ファイルオフセットとは、ファイル内での相対位置を示す。

ＧＣ処理により、Ｊａｖａヒープ領域１２２から外部ヒープ領域１１０にオブジェクトが再配置される場合には、仮想的な論理アドレスを再配置先とし、オブジェクトアドレス３７０１に記録する。そして、当該オブジェクトの参照元オブジェクトには、再配置先とされた仮想的な論理アドレスをオブジェクト参照として設定する。

インポート処理により、外部ヒープ領域１１０からＪａｖａヒープ領域１２２にオブジェクトが再配置される場合には、アクセスされた論理アドレスに基づいてオブジェクトアドレス３７０１を順に検索する。そして、該当するオブジェクトアドレス３７０１が検索された場合には、対応するファイルオフセット３７０２のフィールドから、アクセスされたオブジェクトの実体が記録されたファイル１０５のファイルオフセットを取得し、ファイル１０５に記録されたオブジェクトの実データにアクセスする。

例えば、アクセスされた論理アドレスが“０ｘ６４２ａ４ａｂ０”であった場合、当該アドレスは、オブジェクトアドレスのフィールド３７０３が保持する論理アドレスより大きく、オブジェクトアドレスのフィールド３７０４が保持する論理アドレスより小さいため、オブジェクトの実体は、オブジェクトアドレスのフィールド３７０３に対応するファイルオフセットのフィールド３７０５から取得される。なお、外部ヒープ領域１１０を対象とするＧＣ処理においてオブジェクトの実データにアクセスする場合も、同様の手順によって実データにアクセスすることができる。また、インポート処理の際には、外部ヒープ領域１１０からＪａｖａヒープ領域１２２に再配置されたオブジェクトを特定するファイルオフセットマップ２１７のオブジェクトアドレス３７０１をＮＵＬＬ値で更新しておく。

ここで、オブジェクトアドレス３７０１にＮＵＬＬ値が格納されている場合には、オブジェクトアドレス３７０１によって特定される仮想的なオブジェクトと、それに対応するオブジェクトの実体が不要であることを表す。また、ファイルオフセット３７０２に負数が保持されている場合には、対応するオブジェクトの実体を再配置している途中であることを示し、インポート処理におけるオブジェクトの実体へのアクセスは、オブジェクトの実体の再配置が完了するまで待機させることができる。

以下、本発明の実施の形態のリークオブジェクトを検出する方法の概要を説明する。

図１０は、本発明の実施の形態のページトラップ検出部１１１、メソッド実行部１２３、及びリークオブジェクト検査部２０６による処理の実行遷移を示す図である。

本発明の実施の形態のリークオブジェクト検出方法では、まず、メソッド実行の前にアクセス領域検査前処理を実行する（ステップ３０１）。メソッド実行中には、アクセス領域検査処理を実行し（ステップ３０６）、リークオブジェクト検査処理を終了する前に非アクセスオブジェクトアドレス収集処理を実行する（ステップ３１１）。

アクセス領域検査前処理では、Ｊａｖａヒープ領域１２２のリークオブジェクト検出領域３２０１に対し、メソッド実行中におけるリークオブジェクト検出領域３２０１に格納されたオブジェクトに対するアクセスを検知するためのページトラップを設定する。状態３０２は、ページトラップ設定後のリークオブジェクト検出領域３２０１の状態である。図１０では、Ｊａｖａヒープ領域１２２を４つのページに分割し、アクセスされていないページに斜線を付している。状態３０２は、すべてのページがアクセスされていない状態を示している。

アクセス領域検査前処理３０１が終了すると、プロセッサ１３１は、メソッドを実行する（ステップ３０３）。なお、アクセス領域検査前処理の詳細については、図１６にて後述する。

プロセッサ１３１は、メソッド実行中にリークオブジェクト検出領域３２０１に含まれるオブジェクトにアクセスされると、オペレーティングシステム１２８を経由して、ページトラップ検出部１１１に通知する（ステップ３０４）。

ページトラップ検出部１１１は、通知された内容に基づいて、アクセス領域検査部２０１にアクセス領域検査処理を要求する（ステップ３０５）。さらに、メソッド実行部１２３による処理からアクセス領域検査部２０１による処理に遷移する（ステップ３０６）。

アクセス領域検査処理を実行後は、再びメソッド実行部１２３による処理に実行が遷移し、メソッド実行が継続される（ステップ３０７）。この時点で、アクセス領域検査実行後のリークオブジェクト検出領域３２０１の状態は、状態３０８のようになる。状態３０８では、アクセスされたページを空白として示している。なお、アクセス領域検査処理の概要は図１１にて後述し、詳細は図１７にて後述する。

プロセッサ１３１は、メソッド実行が継続されると、リークオブジェクト検出領域３２０１のページトラップをアクセス状況に応じて解除する。例えば、リークオブジェクト検出領域３２０１の状態は、順次、状態３０９及び状態３１０のようになる。

ここで、プロセッサ１３１は、非アクセスオブジェクトアドレス収集処理要求２０４を受け付けると、メソッド実行部１２３の処理から非アクセスオブジェクトアドレス収集部２０３の処理に遷移し（ステップ３１１）、リークオブジェクト検査処理を終了する。なお、非アクセスオブジェクト収集処理の概要は図１２にて後述し、詳細は図１８にて後述する。

なお、本発明の実施の形態では、ＧＣ実行部１１５によって非アクセスオブジェクトアドレス収集処理が要求される。アクセス領域検査処理の実行回数又はアクセス領域検査の実行時間に基づいて、アクセス領域検査部２０１によって非アクセスオブジェクトアドレス収集処理の実行を要求するようにしてもよい。

また、外部ヒープ領域１１０には、メソッド実行中に外部ヒープ領域１１０に格納されたリークオブジェクト１１２に対するアクセスを検知するためのページトラップが設定されている。メソッド実行中に外部ヒープ領域１１０に格納されたリークオブジェクト１１２にアクセスされると、その旨がページトラップ検出部１１１に通知される。ページトラップ検出部１１１は、通知の内容に基づいて、インポート実行部１１４にインポート処理を要求する。

プロセッサ１３１は、インポート処理が要求されると、メソッド実行部１２３による処理からインポート実行部１１４による処理に実行を遷移させ、インポート処理を実行する。インポート処理は、外部ヒープ領域１１０に再配置することによって、ＧＣ処理の対象外とされていたリークオブジェクト１１２を、Ｊａｖａヒープ領域１２２に再配置することによってＧＣ処理の対象に戻す処理である。インポート処理の実行後は、メソッド実行部１２３の処理に再び実行が遷移し、メソッド実行を継続する。なお、インポート処理の詳細については、図３３にて後述する。

図１１は、本発明の実施の形態のアクセス領域検査部２０１によるアクセス領域検査処理の概要を示す図である。

アクセス領域検査処理では、アクセスページ４０８のページトラップが解除される（ステップ４０６）。なお、アクセスページ４０８とは、メソッドの実行によってアクセスされたアクセスオブジェクト４０４が配置されたリークオブジェクト検出領域３２０１に含まれるページである。リークオブジェクト検出領域３２０１の状態は、ページトラップを解除する前後において、状態４０１から状態４０７のように変化する。

また、アクセスページ４０８のページトラップを解除する場合には、必要とするリークオブジェクトの検出精度に応じて、実際にアクセスされたアドレスであるアクセスアドレス４０２をアクセスアドレステーブル２０２に登録する（ステップ４０５）。

なお、アクセスオブジェクト４０４の先頭アドレスであるアクセスオブジェクトアドレス４０３であってもよい。この場合には、アクセス領域検査処理３０７のオーバーヘッドは大きくなるが、アクセスオブジェクトアドレス４０３を取得する処理を以降省略することができる。本発明の実施の形態では、アクセス領域検査処理３０７ではアクセスアドレス４０２をアクセスアドレステーブル２０２に登録し、ＧＣ処理において必要に応じてアクセスアドレス４０２からアクセスオブジェクトアドレス４０３を取得する。

図１２は、本発明の実施の形態の非アクセスオブジェクトアドレス収集部２０３による非アクセスオブジェクトアドレス収集処理の概要を示す図である。

非アクセスオブジェクトアドレス収集処理では、非アクセスページ５０１に配置されたオブジェクトである非アクセスオブジェクト５０２が取得される。そして、非アクセスオブジェクト５０２の先頭アドレスである非アクセスオブジェクトアドレス５０３が非アクセスオブジェクトアドレステーブル２０５に登録される（ステップ５０４）。

なお、非アクセスページ５０１とは、リークオブジェクト検出領域３２０１に含まれ、アクセス領域検査処理３０７によってページトラップが解除されなかったページである。また、本発明の実施の形態では、オブジェクト全体が非アクセスページ５０１に含まれない場合には、アクセスオブジェクト４０４として扱っている。

以下、本発明の実施の形態によるリークオブジェクト検出方法における各部の処理について説明する。

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

プロセッサ１３１は、メソッド実行部１２３を実行する前に、まず、ＪａｖａＶＭ１０９が受け付けたＪａｖａクラスファイル１０３を解析する。次に、メソッド読み取り部１１３によって、Ｊａｖａクラスファイル１０３からメソッドを抽出し、動的コンパイラ部１１６によって、コンパイルコード１２５を生成する。プロセッサ１３１は、生成されたコンパイルコード１２５を順次実行する。コンパイルコード１２５は、一つ以上の命令を含み、各命令には、命令種別が付与されている。

メソッド実行部１２３では、実行対象のメソッドの命令種別に基づいて処理が実行される。

プロセッサ１３１は、まず、実行対象のメソッドの命令種別がメモリ確保命令であるか否かを判定する（ステップ６０１）。命令種別がメモリ確保命令でなかった場合には（ステップ６０１の結果が「ＮＯ」）、対象の命令を実行する（ステップ６０４）。

プロセッサ１３１は、命令種別がメモリ確保命令であった場合には（ステップ６０１の結果が「ＹＥＳ」）、メモリ確保部１２１を実行し、メモリ確保処理を実行する（ステップ６０２）。メモリ確保処理が終了した後には、メモリ確保が成功したか否かを判定する（ステップ６０３）。

プロセッサ１３１は、メモリの確保に失敗した場合には（ステップ６０３の結果が「ＮＯ」）、メソッドの実行を中断し、メモリ不足エラーを発生させる（ステップ６０５）。

プロセッサ１３１は、メモリの確保に成功した場合（ステップ６０３の結果が「ＹＥＳ」）、又は、ステップ６０４の処理が終了した場合には、次に実行すべき命令があるか否かを判定する（ステップ６０６）。

プロセッサ１３１は、次に実行すべき命令がある場合には（ステップ６０６の結果が「ＹＥＳ」）、ステップ６０１の処理を実行し、メソッド実行処理を継続する。すべての命令の処理が終了した場合には（ステップ６０６の結果が「ＮＯ」）、メソッド実行処理を終了する。

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

プロセッサ１３１は、Ｊａｖａヒープ領域１２２に要求された量のメモリを確保可能か否かを判定する（ステップ７０１）。具体的には、まず、Ｊａｖａヒープ領域管理テーブル２１３を参照し、未使用領域先頭３１０４及び領域終端３１０５の値を取得する。次に、Ｊａｖａヒープ領域１２２のメモリ未使用量を算出し、要求されたメモリ使用量と比較する。

プロセッサ１３１は、要求された量のメモリがＪａｖａヒープ領域１２２に確保可能でない場合には（ステップ７０１の結果が「ＮＯ」）、不要なメモリ領域を解放するためにＧＣ処理を実行する（ステップ７０２）。なお、ＧＣ処理の詳細については、図１９にて後述する。

プロセッサ１３１は、ＧＣ処理の実行後、Ｊａｖａヒープ領域１２２に要求された量のメモリが確保可能か否かを再び判定する（ステップ７０３）。要求された量のメモリをＪａｖａヒープ領域１２２に確保できなかった場合には（ステップ７０３の結果が「ＮＯ」）、メモリ確保処理の実行元にメモリ確保に失敗した旨を通知する（ステップ７０９）。

プロセッサ１３１は、要求された量のメモリをＪａｖａヒープ領域１２２に確保可能な場合には（ステップ７０１又はステップ７０３の結果が「ＹＥＳ」）、Ｊａｖａヒープ領域１２２に要求された量のメモリを確保し、確保されたメモリサイズに基づいて未使用領域先頭３１０４のアドレスを更新する（ステップ７０４）。

次に、プロセッサ１３１は、リークオブジェクトの検出処理を実行するか否かを判定する（ステップ７０５）。具体的には、Ｊａｖａヒープ領域管理テーブル２１３から領域先頭３１０１及び未使用領域先頭３１０４を取得し、Ｊａｖａヒープ領域１２２のメモリ使用量を算出する。取得されたＪａｖａヒープ領域１２２のメモリ使用量に基づいて、リークオブジェクト検出管理情報２０８のリークオブジェクト検出実行条件３００２と比較する。

プロセッサ１３１は、リークオブジェクトの検出処理を実行する場合には（ステップ７０５の結果が「ＹＥＳ」）、リークオブジェクト検出管理情報２０８のリークオブジェクト検出実行フラグ３００１を“１”に設定する（ステップ７０７）。リークオブジェクトの検出処理を実行しない場合には（ステップ７０５の結果が「ＮＯ」）、リークオブジェクト検出管理情報２０８のリークオブジェクト検出実行フラグ３００１を“０”に設定する（ステップ７０６）。

プロセッサ１３１は、ステップ７０６の処理又はステップ７０７の処理が終了すると、メモリ確保処理の実行元に確保されたメモリを通知する（ステップ７０８）。ステップ７０８の処理又はステップ７０９の処理が終了すると、本処理は終了する。

図１５は、本発明の実施の形態のページトラップ検出処理の手順を示すフローチャートである。本処理は、プロセッサ１３１がページトラップ検出部１１１を処理することによって実行される。ページトラップ検出部１１１は、ＪａｖａＶＭの実行中に主記憶に常駐させてもよい。

プロセッサ１３１は、オペレーティングシステム１２８からページトラップが発生した旨の通知を受けると、ページトラップが発生した領域を判定する（ステップ８０１）。具体的には、Ｊａｖａヒープ領域管理テーブル２１３の領域先頭３１０１と領域終端３１０５、及び、外部ヒープ領域管理テーブル２１４の領域先頭３１０６と領域終端３１０８を参照し、受け付けた通知内容に基づいて判定する。

プロセッサ１３１は、Ｊａｖａヒープ領域１２２でページトラップが発生していた場合には（ステップ８０１の結果が「Ｊａｖａヒープ領域」）、アクセス領域検査部２０１を実行することによって、アクセス領域検査処理を開始する（ステップ８０２）。

プロセッサ１３１は、外部ヒープ領域１１０でページトラップが発生していた場合には（ステップ８０１の結果が「外部ヒープ領域」）、インポート実行部１１４を実行することによって、インポート処理を開始する（ステップ８０４）。

プロセッサ１３１は、Ｊａｖａヒープ領域１２２及び外部ヒープ領域１１０以外の領域でページトラップが発生した場合には（ステップ８０１の結果が「その他」）、当該ページトラップに対して要求された処理を実行する（ステップ８０３）。

ステップ８０２の処理、ステップ８０３の処理又はステップ８０４の処理が終了すると、本処理は終了する。

図１６は、本発明の実施の形態のアクセス領域検査前処理の手順を示すフローチャートである。本処理は、プロセッサ１３１がリークオブジェクト検査部２０６の処理において、メソッド実行前に実行される。

プロセッサ１３１は、まず、リークオブジェクト検出管理情報２０８のリークオブジェクト検出実行フラグ３００１を参照し、アクセス領域検査を実行するか否かを判定する（ステップ９０１）。

プロセッサ１３１は、アクセス領域検査を実行する場合には（ステップ９０１の結果が「ＹＥＳ」）、リークオブジェクト検出管理情報２０８のリークオブジェクト検出領域ページ数３００３に基づいて、Ｊａｖａヒープ領域１２２のリークオブジェクト検出領域３２０１に対応する領域にページトラップを設定する（ステップ９０２）。

次に、プロセッサ１３１は、リークオブジェクト検出管理情報２０８のオブジェクト整列実行フラグ３００６を参照し、ＧＣ処理によるオブジェクト再配置の際にオブジェクト整列を実行するか否かを判定する（ステップ９０３）。

プロセッサ１３１は、ＧＣ処理によるオブジェクト再配置の際にオブジェクト整列を実行する場合には（ステップ９０３の結果が「ＹＥＳ」）、アクセス領域検査処理で使用されるアクセスアドレステーブル２０２を作成する（ステップ９０４）。

アクセス領域検査を実行しない場合（ステップ９０１の結果が「ＮＯ」）、ＧＣ処理によるオブジェクト再配置の際にオブジェクト整列を実行しない場合（ステップ９０３の結果が「ＮＯ」）、又はステップ９０４の処理が終了すると、本処理は終了する。

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

プロセッサ１３１は、まず、リークオブジェクト検出管理情報２０８のオブジェクト整列実行フラグ３００６を参照し、ＧＣ処理におけるオブジェクト再配置の際にオブジェクト整列を実行するか否かを判定する（ステップ１００１）。

プロセッサ１３１は、ＧＣ処理におけるオブジェクト再配置の際にオブジェクト整列を実行する場合には（ステップ１００１の結果が「ＹＥＳ」）、アクセスアドレス４０２をアクセスアドレステーブル２０２に登録する（ステップ１００２）。

プロセッサ１３１は、ＧＣ処理によるオブジェクト再配置の際にオブジェクト整列を実行しない場合（ステップ１００１の結果が「ＮＯ」）、又は、ステップ１００２の処理の終了後には、当該アクセスページにおけるアクセス領域検査を終了するか否かを判定する（ステップ１００３）。具体的には、アクセスアドレステーブル２０２の当該アクセスページに対するブロックへの登録数と、リークオブジェクト検出管理情報２０８のアクセスアドレス収集回数３００４とを比較することによって、当該アクセスページにおけるアクセス領域検査を終了するか否かを判定する。

プロセッサ１３１は、アクセス領域検査処理を終了する場合には（ステップ１００３の結果が「ＹＥＳ」）、当該アクセスページのページトラップを解除する（ステップ１００４）。アクセスページのページトラップを解除すると、次回のリークオブジェクト検査まで、当該アクセスページにおけるアクセス領域検査を実行しない。こうすることによって、リークオブジェクトの検出処理に伴うメソッド実行中のオーバーヘッドを抑制することができる。

アクセス領域検査処理を終了しない場合（ステップ１００３の結果が「ＮＯ」）、又はステップ１００４の処理が終了すると、本処理は終了する。

図１８は、本発明の実施の形態の非アクセスオブジェクトアドレス収集処理の手順を示すフローチャートである。本処理は、プロセッサ１３１が非アクセスオブジェクトアドレス収集部２０３を処理することによって実行される。本処理は、リークオブジェクトの検出処理の実行時に、非アクセスオブジェクトアドレス収集処理要求２０４を受け付けたときに実行される。

プロセッサ１３１は、まず、リークオブジェクト検出領域３２０１に未処理の非アクセスページ５０１が存在するか否かを判定する（ステップ１１０１）。リークオブジェクト検出領域３２０１に未処理の非アクセスページ５０１がある場合には（ステップ１１０１の結果が「ＹＥＳ」）、当該非アクセスページのページトラップを解除する（ステップ１１０２）。

次に、プロセッサ１３１は、ページトラップが解除されたページ内に未処理の非アクセスオブジェクト５０２が存在するか否かを判定する（ステップ１１０４）。リークオブジェクト検出領域３２０１に未処理の非アクセスオブジェクト５０２がある場合には（ステップ１１０４の結果が「ＹＥＳ」）、非アクセスオブジェクトアドレステーブル２０５の非アクセスオブジェクトアドレス３３０１を参照し、当該オブジェクトのアドレスが登録済みか否かを判定する（ステップ１１０５）。

プロセッサ１３１は、当該オブジェクトのアドレスが登録済みの場合には（ステップ１１０５の結果が「ＹＥＳ」）、当該オブジェクトアドレスに対応する非アクセスオブジェクトアドレステーブル２０５の非アクセス回数３３０２の値を“１”増やす（ステップ１１０６）。

プロセッサ１３１は、当該オブジェクトのアドレスが登録済みでない場合には（ステップ１１０５の結果が「ＮＯ」）、非アクセスオブジェクトアドレステーブル２０５の非アクセスオブジェクトアドレス３３０１に“当該オブジェクトのアドレス”、非アクセス回数３３０２に“１”を登録する（ステップ１１０７）。

プロセッサ１３１は、リークオブジェクト検出領域３２０１に未処理の非アクセスオブジェクト５０２が存在しない場合（ステップ１１０４の結果が「ＮＯ」）、ステップ１１０６の処理の終了後、又はステップ１１０７の処理の終了後には、ステップ１１０１の処理を実行し、非アクセスオブジェクトアドレス収集処理を継続する。

プロセッサ１３１は、リークオブジェクト検出領域３２０１に未処理の非アクセスページ５０１が存在しない場合には（ステップ１１０１の結果が「ＮＯ」）、非アクセスオブジェクトアドレステーブル２０５で更新されていない非アクセスオブジェクトアドレス３３０１のレコードを削除する（ステップ１１０３）。ステップ１１０３の処理が終了すると、本処理は終了する。

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

プロセッサ１３１は、まず、ＧＣ処理を実行するスレッド以外の全スレッドを停止する（ステップ１３０１）。次に、非アクセスオブジェクトアドレス収集部２０３を処理することによって、非アクセスオブジェクトアドレス収集処理を実行する（ステップ３１１）。非アクセスオブジェクトアドレス収集処理は、図１８にて前述した処理である。

プロセッサ１３１は、Ｊａｖａヒープ領域１２２を走査しながら、アクセスアドレステーブル２０２に登録されたアクセスアドレス４０２に基づいてアクセスオブジェクトアドレス４０３を取得し、アクセスアドレス４０２をアクセスオブジェクトアドレス４０３に置き換える（ステップ１３０３）。なお、リークオブジェクト検出管理情報２０８のオブジェクト整列実行フラグ３００６に基づいて、アクセスアドレステーブル２０２にアクセスアドレス４０２が登録されなかった場合には、ステップ１３０３の処理では何も処理しない。

プロセッサ１３１は、オブジェクト種別判定部２０９を処理することによってオブジェクト種別判定処理を実行し、Ｊａｖａヒープ領域１２２に記憶されたすべてのオブジェクトのオブジェクト種別を判定する（ステップ１３０４）。なお、オブジェクト判定処理の詳細については、図２１にて後述する。

プロセッサ１３１は、再配置アドレス計算部２１０を処理することによって再配置アドレス計算処理を実行し、ステップ１３０４の処理で判定されたオブジェクト種別に基づいて、オブジェクトを再配置するアドレスを計算する（ステップ１３０５）。なお、再配置アドレス計算処理の詳細については、図３０にて後述する。

プロセッサ１３１は、オブジェクト参照更新部２１１を実行することによって、オブジェクト参照の参照先がステップ１３０５の処理で計算された参照先オブジェクトの再配置アドレスになるようにオブジェクト参照を更新する（ステップ１３０６）。

プロセッサ１３１は、再配置実行部２１２を処理することによって再配置実行処理を実行し、ステップ１３０５の処理で計算されたオブジェクトの再配置アドレスにオブジェクトを実際に再配置する（ステップ１３０７）。なお、再配置実行処理の詳細については、図３１にて後述する。

最後に、プロセッサ１３１は、停止されていたスレッドの実行を再開し（ステップ１３０８）、本処理を終了する。

図２０は、本発明の実施の形態のＧＣ処理７０２の処理過程において、Ｊａｖａヒープ領域１２２及び外部ヒープ領域１１０の状態を示す図である。図２０では、上段にオブジェクト種別判定処理１３０４の実行後、中段に再配置アドレス計算処理１３０５の実行後、及び、下段に再配置実行処理１３０７の実行後の状態を示している。ここでは各状態の概要を説明し、詳細については各処理の手順とともに説明する。

図２０の上段に示されたオブジェクト種別判定処理１３０４の実行後の状態は、Ｊａｖａヒープ領域１２２に格納されたオブジェクトにオブジェクト種別が付与されている。なお、“Ｌ”はリークオブジェクト、“Ｒ”はアクセスオブジェクト、“Ｓ”は生存オブジェクトを示している。なお、オブジェクト種別に付随する数字はオブジェクト種別が同じである個々のオブジェクトを識別するために便宜上付加したのものである。アクセスオブジェクトは、リークオブジェクトの検出処理によってアクセスされたと判定されたオブジェクトである。生存オブジェクトは、今回のＧＣ処理７０２が実行されたリークオブジェクトの検出処理ではアクセスされていないが、最近アクセスされたオブジェクトである。

図２０の中段に示された再配置アドレス計算処理１３０５の実行後の状態は、オブジェクト種別判定処理１３０４によって各オブジェクトに付与されたオブジェクト種別に基づいて再配置されるアドレスが計算されている。

図２０の下段に示された再配置実行処理１３０７の実行後の状態は、再配置アドレス計算処理１３０５の計算結果に基づいて、オブジェクトが再配置された後の状態である。

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

プロセッサ１３１は、まず、オブジェクトヘッダ３４０１のオブジェクト種別を“デッド”の状態に初期化する（ステップ１４０１）。

次に、プロセッサ１３１は、生存オブジェクトマーキング処理を実行する（ステップ１４０２）。生存オブジェクトマーキング処理は、生存オブジェクトのオブジェクトヘッダ３４０１をオブジェクト種別“生存”の状態に設定する。図２２に生存オブジェクトマーキング処理１４０２の終了時点のＪａｖａヒープ領域１２２及び外部ヒープ領域１１０の状態を示す。

図２２は、本発明の実施の形態のオブジェクト種別判定処理の生存オブジェクトマーキング処理１４０２の終了時点におけるＪａｖａヒープ領域１２２及び外部ヒープ領域１１０に格納されたオブジェクトの状態を示す図である。

各ノードは、オブジェクトを示している。二重丸で示されたオブジェクトは、生存オブジェクトマーキング処理によってオブジェクトヘッダ３４０１が更新されたオブジェクトである。なお、ノード内の記号は、“Ｓ”は生存オブジェクト、“Ｄ”はデッドオブジェクトを示している。

また、オブジェクトを連結する矢印は、オブジェクトの参照関係を示している。実線の矢印は、Ｊａｖａヒープに格納されたオブジェクトに対する参照を示している。点線の矢印は、外部ヒープ領域１１０に格納されたオブジェクトに対する参照を示している。

ルートセット２００１は、プログラム実行環境からアプリケーション実行中に直接参照されるレジスタ、スタック又は静的変数などの領域である。ルートセット２００１に保持されるオブジェクト参照を起点として生存オブジェクトマーキング処理が実行されると、ルートセット２００１からオブジェクト参照を辿ることによって到達可能なオブジェクトはすべて生存オブジェクトと判定される。

したがって、図２２に示すようにプロキシオブジェクト２００２及び“Ｓ”が付されたオブジェクトはすべて生存オブジェクトである。なお、生存オブジェクトマーキング処理については図２６、プロキシオブジェクト２００２については図２９Ａにて後述する。

ここで、図２１のオブジェクト種別判定処理のフローチャートの説明に戻る。

プロセッサ１３１は、非アクセスオブジェクトアドレステーブル２０５に登録された非アクセスオブジェクトアドレス５０３によって特定される非アクセスオブジェクトに対して、リークオブジェクト判定処理を実行する。そして、リークオブジェクト判定処理の結果に基づいて、リークオブジェクトと判定された非アクセスオブジェクト５０２のオブジェクトヘッダ３４０１にオブジェクト種別“リーク”を設定する（ステップ１４０３）。図２３にステップ１４０３の処理の終了時点のＪａｖａヒープ領域１２２及び外部ヒープ領域１１０の状態を示す。なお、リークオブジェクト判定処理の詳細については、図２７にて後述する。

図２３は、本発明の実施の形態のオブジェクト種別判定処理のリークオブジェクト判定処理１４０３の処理の終了時点におけるＪａｖａヒープ領域１２２及び外部ヒープ領域１１０に格納されたオブジェクトの状態を示す図である。

二重丸で示されたオブジェクトは、リークオブジェクト判定処理１４０３によってオブジェクト種別が更新されたオブジェクトである。具体的には、“Ｌ”が付され、リークオブジェクトと判定されている。

ここで、図２１のオブジェクト種別判定処理のフローチャートの説明に戻る。

次に、プロセッサ１３１は、ステップ１４０３の処理によってオブジェクト種別が“リーク”に設定されたリークオブジェクトについて、プロキシオブジェクト登録処理を実行する（ステップ１４０４）。

プロセッサ１３１は、リークオブジェクトが生存オブジェクトを参照している場合には、プロキシオブジェクト２００２から参照先の生存オブジェクトを参照できるように、参照先の生存オブジェクトのアドレスをプロキシオブジェクト２００２に登録する。

リークオブジェクトによって参照されている生存オブジェクトは、便宜上、合流オブジェクトとされる。また、合流オブジェクトの実体は生存オブジェクトであるため、合流オブジェクトのオブジェクトヘッダ３４０１には、“生存”のオブジェクト種別が設定される。図２４にステップ１４０４の処理の終了時点のＪａｖａヒープ領域１２２及び外部ヒープ領域１１０の状態を示す。

図２４は、本発明の実施の形態のオブジェクト種別判定処理のプロキシオブジェクト登録処理１４０４の終了時点におけるＪａｖａヒープ領域１２２及び外部ヒープ領域１１０に格納されたオブジェクトの状態を示す図である。“Ｊ”が付された二重丸で示されたオブジェクトは、合流オブジェクトを示す。

図２４に示す状態では、合流オブジェクト２２０２及び合流オブジェクト２２０４が含まれている。オブジェクト２２０１及びオブジェクト２２０３は、合流オブジェクト２２０２及び合流オブジェクト２２０４を参照するリークオブジェクトである。リークオブジェクト２２０１及びリークオブジェクト２２０３は、後述する再配置実行処理１３０７によって、外部ヒープ領域１１０に再配置される。

合流オブジェクト２２０２及び合流オブジェクト２２０４は、ＧＣ処理完了後に、外部ヒープ領域１１０からＪａｖａヒープ領域１２２への参照の合流点になる。外部ヒープ領域１１０に再配置されたリークオブジェクトは、ＧＣ処理の対象外となるため、生存オブジェクトマーキング処理１４０２において、外部ヒープ領域１１０からＪａｖａヒープ領域１２２に参照が辿られることはない。したがって、次回のＧＣ処理実行の際に、合流オブジェクト２２０２及び合流オブジェクト２２０４から参照を辿ることによって到達可能な生存オブジェクトが誤ってオブジェクト種別“デッド”と判定され、回収されてしまう可能性がある。

プロキシオブジェクト２００２は、合流オブジェクト２２０２及び合流オブジェクト２２０４を参照するため、ＧＣ処理によって誤ってオブジェクトが回収されることを防止できる。プロキシオブジェクト２００２を用意することによって、参照関係にあるオブジェクトをＧＣ処理の対象である領域とＧＣ処理の対象外である領域の両方に配置することができる。なお、プロキシオブジェクト登録処理１４０４の詳細については、図２８にて後述する。

ここで、図２１のオブジェクト種別判定処理のフローチャートの説明に戻る。

最後に、プロセッサ１３１は、アクセスアドレステーブル２０２に登録されたアクセスオブジェクトアドレス４０３によって特定されるアクセスオブジェクト４０４のオブジェクトヘッダ３４０１にオブジェクト種別“アクセス”を設定する（ステップ１４０５）。ステップ１４０５の処理が終了すると、本処理は終了する。図２５にステップ１４０５の処理の終了時点のＪａｖａヒープ領域１２２及び外部ヒープ領域１１０の状態を示す。

図２５は、本発明の実施の形態のオブジェクト種別判定処理の終了時点におけるＪａｖａヒープ領域１２２及び外部ヒープ領域１１０に格納されたオブジェクトの状態を示す図である。

二重丸で示されたオブジェクトは、ステップ１４０５の処理によってオブジェクト種別が更新されたオブジェクトである。具体的には、“Ａ”が付されたアクセスオブジェクトである。アクセスオブジェクトであるか否かは、前述のようにアクセスアドレステーブル２０２に登録された情報に基づいて判定される。

また、オブジェクト種別判定処理が終了すると、Ｊａｖａヒープ領域１２２に格納されたオブジェクトのオブジェクト種別は図２０の上段に示すよう判別可能になる。なお、図２０の上段に示すように、オブジェクトが互いに隙間なく配置されるか否かはメモリ管理部１２４のメモリ管理方針に依存する。本発明の実施の形態では、図２０の上段に示すように、オブジェクトを互いに隙間なく配置させる。

図２６は、本発明の実施の形態のオブジェクト種別判定処理における生存オブジェクトマーキング処理の手順を示すフローチャートである。本処理は、Ｊａｖａヒープ領域１２２に格納された生存オブジェクトのオブジェクトヘッダ３４０１に“生存”のオブジェクト種別を設定する。また、本処理の対象は、ルートセット２００１から到達可能なＪａｖａヒープ領域１２２に格納されたオブジェクトである。

プロセッサ１３１は、まず、処理対象のオブジェクトのオブジェクト参照に未処理のオブジェクト参照が存在するか否かを判定する（ステップ１５０１）。

プロセッサ１３１は、未処理のオブジェクト参照が存在する場合には（ステップ１５０１の結果が「ＹＥＳ」）、参照先のオブジェクトが外部ヒープ領域１１０に格納されているか否かを判定する（ステップ１５０２）。具体的には、外部ヒープ領域管理テーブル２１４の領域先頭３１０６及び領域終端３１０８を参照し、オブジェクト参照の参照先のアドレスと比較する。外部ヒープ領域１１０に格納されたオブジェクトはリークオブジェクトであるため、本処理の対象となるオブジェクトでない。ステップ１５０２の処理は、参照先のオブジェクトが本処理の対象であるか否かを判定する。

プロセッサ１３１は、参照先のオブジェクトが外部ヒープ領域１１０に格納されていない場合には（ステップ１５０２の結果が「ＮＯ」）、参照先のオブジェクトを新たに処理対象とする（ステップ１５０３）。

次に、プロセッサ１３１は、新たに処理対象となったオブジェクトのオブジェクトヘッダ３４０１を参照し、オブジェクト種別が“デッド”であるか否かを判定する（ステップ１５０４）。なお、本処理の開始前に、Ｊａｖａヒープ領域１２２に格納されたオブジェクトのオブジェクト種別は、すべて“デッド”に初期化されている（図２１のステップ１４０１）。

プロセッサ１３１は、オブジェクト種別が“デッド”である場合には（ステップ１５０４の結果が「ＹＥＳ」）、オブジェクトヘッダ３４０１にオブジェクト種別“生存”を設定する（ステップ１５０５）。

プロセッサ１３１は、処理対象のオブジェクトの参照先オブジェクトに対して生存オブジェクトマーキング処理を再帰的に実行する（ステップ１４０２）。

プロセッサ１３１は、オブジェクト種別が“デッド”でない場合（ステップ１５０４の結果が「ＮＯ」）、又はステップ１５０６の処理の終了後には、処理対象のオブジェクトの参照元オブジェクトを新たに処理対象のオブジェクトとする（ステップ１５０７）。

プロセッサ１３１は、参照先のオブジェクトが外部ヒープ領域１１０に格納されている場合（ステップ１５０２の結果が「ＹＥＳ」）、又はステップ１５０７の処理の終了後には、ステップ１５０１の処理に戻る。そして、未処理のオブジェクトに対して生存オブジェクトマーキング処理１４０２の実行を継続する。

プロセッサ１３１は、未処理のオブジェクト参照が存在しない場合には（ステップ１５０１の結果が「ＮＯ」）、すべての処理対象のオブジェクトに対する生存オブジェクトマーキング処理が完了したため、本処理を終了する。

図２７は、本発明の実施の形態のリークオブジェクト判定処理の手順を示すフローチャートである。リークオブジェクト判定処理は、処理対象のオブジェクトがリークオブジェクトであるか否かを判定する。本処理は、プロセッサ１３１がリークオブジェクト判定部２０７を処理することによって実行される。

プロセッサ１３１は、まず、処理対象のオブジェクトがリークオブジェクトに該当するか否かを判定する（ステップ１６０１）。具体的には、非アクセスオブジェクトアドレステーブル２０５を参照し、処理対象のオブジェクトの非アクセス回数３３０２とリークオブジェクト検出管理情報２０８のリークオブジェクト条件３００５とを比較する。

プロセッサ１３１は、処理対象のオブジェクトがリークオブジェクトの条件を満たしている場合には（ステップ１６０１の結果が「ＹＥＳ」）、当該オブジェクトがリークオブジェクトである旨を本処理の実行元に通知する（ステップ１６０２）。実行元の処理において、処理対象のオブジェクトのオブジェクト種別を“リーク”に更新する（図２１のステップ１４０３）。

プロセッサ１３１は、処理対象のオブジェクトがリークオブジェクトの条件を満たしていない場合には（ステップ１６０１の結果が「ＮＯ」）、当該オブジェクトが非リークオブジェクトである旨を本処理の実行元に通知する（ステップ１６０３）。

ステップ１６０２の処理又はステップ１６０３の処理の終了後、本処理は終了する。

図２８は、本発明の実施の形態のプロキシオブジェクト登録処理の手順を示すフローチャートである。プロキシオブジェクト登録処理は、リークオブジェクトに参照された生存オブジェクトをプロキシオブジェクトに登録する処理である。本処理は、リークオブジェクトに対して実行される。

プロセッサ１３１は、まず、処理対象のオブジェクトのオブジェクト参照で未処理のオブジェクト参照が存在するか否かを判定する（ステップ１７０１）。

プロセッサ１３１は、未処理のオブジェクト参照が存在する場合には（ステップ１７０１の結果が「ＹＥＳ」）、当該オブジェクト参照の参照先が外部ヒープ領域１１０であるか否かを判定する（ステップ１７０２）。具体的には、図２６のステップ１５０２の処理と同じく、外部ヒープ領域管理テーブル２１４の領域先頭３１０６及び領域終端３１０８を参照し、オブジェクト参照の参照先のアドレスと比較する。外部ヒープ領域１１０に格納されたオブジェクトはリークオブジェクトであるため、本処理の対象となるオブジェクトでない。ステップ１７０２の処理は参照先のオブジェクトが本処理の対象であるか否かを判定する。

プロセッサ１３１は、参照先のオブジェクトが外部ヒープ領域１１０に格納されていない場合には（ステップ１７０２の結果が「ＮＯ」）、参照先オブジェクトが生存オブジェクトであるか否かを判定する（ステップ１７０３）。具体的には、参照先オブジェクトのオブジェクトヘッダ３４０１に格納されたオブジェクト種別を参照し、オブジェクト種別が“生存”であるか否かを判定する。

プロセッサ１３１は、参照先オブジェクトが生存オブジェクトである場合には（ステップ１７０３の結果が「ＹＥＳ」）、参照先オブジェクトのアドレスをプロキシオブジェクト２００２が保持する未登録のオブジェクト参照に登録する。さらに、登録されたプロキシオブジェクト２００２が保持するオブジェクト参照の識別子を取得する。そして、当該識別子を処理対象のオブジェクトのオブジェクト参照に記録する（ステップ１７０４）。ここで、図２９Ａを参照しながらプロキシオブジェクトの構造を説明し、さらに、ステップ１７０４の処理を、具体例を示しながら説明する。

図２９Ａは、本発明の実施の形態のプロキシオブジェクト２００２の構造を示す図である。

プロキシオブジェクト２００２は、複数のオブジェクト参照を格納可能である。プロキシオブジェクト２００２に格納されるオブジェクト参照には、合流オブジェクトのアドレスが格納される。

また、オブジェクトが保持するオブジェクト参照３６０１は、オブジェクトデータ３４０２に格納され、オブジェクトが保持するオブジェクト参照３６０１の各フィールドは、識別子３６０２によって識別される。本発明の実施の形態では、オブジェクト参照を配列として管理しているため、識別子３６０２はオブジェクト参照配列のインデックスとなる。

プロキシオブジェクト２００２は、本発明の実施の形態において、言語処理システムがオブジェクトの参照関係を管理するためのオブジェクトであって、基本的にはオブジェクト参照のフィールドのみを有する。

プロキシオブジェクトが保持するオブジェクト参照３６０３の各フィールドは、プロキシオブジェクトが保持するオブジェクト参照の識別子３６０４によって識別される。また、プロキシオブジェクトが保持するオブジェクト参照３６０３の各フィールドは、オブジェクト参照更新部２１１によるオブジェクト参照更新処理の対象である。そして、プロキシオブジェクトが保持するオブジェクト参照３６０３によって特定されるオブジェクトがＧＣ処理７０２によって再配置されると、プロキシオブジェクトが保持するオブジェクト参照３６０３が保持するアドレスも更新される。

プロキシオブジェクト２００２は、ルートセット２００１から参照されていれば、Ｊａｖａヒープ領域１２２以外の領域に配置してもよい。なお、本発明の実施の形態では、プロキシオブジェクト２００２をＪａｖａヒープ領域１２２に配置する。

プロキシオブジェクト２００２は、ルートセット２００１から参照されているため、ＪａｖａＶＭ１０９が終了するまで回収されることはない。一方、アプリケーションプログラムを実行中にＪａｖａヒープ領域１２２及び外部ヒープ領域１１０に空き領域がなくなった状態でプロキシオブジェクト２００２がＪａｖａヒープ領域１２２に配置されている場合には、Ｊａｖａヒープ領域１２２の空き領域を増やす目的でプロキシオブジェクト２００２を回収してもよい。なお、プロキシオブジェクト２００２を回収する場合には、オブジェクトのインポート処理を実行することができなくなるため、プロキシオブジェクト２００２を回収する前にインポート処理の実行を禁止する必要がある。

続いて、ステップ１７０４の処理について説明する。処理対象のオブジェクトには、三つのオブジェクト参照が含まれている。オブジェクト参照は、＃０、＃１及び＃２の識別子３６０２が付与されている。また、識別子３６０２が“＃１”であるオブジェクト参照３６０５は、オブジェクト３６０７を参照している。以上の状態を初期状態とする。

以上説明した初期状態に対してステップ１７０４の処理が実行されると、まず、プロキシオブジェクトが保持するオブジェクト参照の識別子３６０４が“＃３”であるオブジェクト参照３６０６は、オブジェクト３６０７を参照するように更新される。さらに、処理対象のオブジェクトが保持するオブジェクト参照の識別子３６０２が“＃１”であるオブジェクト参照３６０５は、プロキシオブジェクトが保持するオブジェクト参照の識別子３６０４が“＃３”であるオブジェクト参照３６０６を参照するように更新される。なお、オブジェクトが保持するオブジェクト参照３６０１は、オブジェクトアドレスを直接保持する場合とプロキシオブジェクトが保持するオブジェクト参照の識別子３６０４を保持する場合がある。

これに対し、図７にて説明したように、オブジェクトへのポインタの下位数ビットは０となるため、本発明の実施の形態では、最下位ビットの状態によって、オブジェクト参照がオブジェクトアドレスとプロキシオブジェクトが保持するオブジェクト参照の識別子３６０４のいずれを保持しているのかを判定することができる。図２９Ｂに３２ビット環境においてオブジェクト参照が保持する値の例を示す。

図２９Ｂは、本発明の実施の形態の３２ビット環境におけるオブジェクト参照に保持される値の一例を示す図である。

図２９Ｂの上段に示すようにオブジェクト参照に保持された値の最下位ビットが“０”の場合には、オブジェクトアドレスそのものがオブジェクト参照に保持されている。

一方、図２９Ｂの下段に示すようにオブジェクト参照に保持された値の最下位ビットが“１”の場合には、プロキシオブジェクトが保持するオブジェクト参照の識別子３６０４がオブジェクト参照に保持されている。具体的には、オブジェクト参照のフィールドの上位３１ビットに保持されており、オブジェクト参照のフィールドからプロキシオブジェクトが保持するオブジェクト参照の識別子３６０４を取り出す場合には、オブジェクト参照のフィールドの値を１ビット右論理シフトした値をプロキシオブジェクトが保持するオブジェクト参照の識別子３６０４として取り出す。また、オブジェクト参照のフィールドにプロキシオブジェクトが保持するオブジェクト参照の識別子３６０４を記録する場合には、プロキシオブジェクトが保持するオブジェクト参照の識別子３６０４の値を１ビット左論理シフトし、最下位ビットを“１”とした値を記録する。

なお、プロキシオブジェクト２００２がアドレス空間に対して固定されて配置されている場合には、プロキシオブジェクトが保持するオブジェクト参照の識別子３６０４の代わりに、プロキシオブジェクトが保持するオブジェクト参照のフィールドのアドレスをオブジェクトが保持するオブジェクト参照３６０１に記録してもよい。プロキシオブジェクト２００２が配置された領域の範囲によって、オブジェクト参照がオブジェクトアドレス又はプロキシオブジェクトが保持するオブジェクト参照の識別子３６０４のいずれかを保持しているのかを判定することが可能である。

ここで、図２８のプロキシオブジェクト登録処理１４０４のフローチャートの説明に戻る。

プロセッサ１３１は、参照先が外部ヒープ領域１１０である場合（ステップ１７０２の結果が「ＹＥＳ」）、オブジェクト種別が“生存”でない場合（ステップ１７０３の結果が「ＮＯ」）、又はステップ１７０４の処理の終了後は、ステップ１７０１の処理に戻り、プロキシオブジェクト登録処理を継続する。

未処理のオブジェクト参照が存在しなくなると（ステップ１７０１の結果が「ＮＯ」）、本処理は終了する。

図３０は、本発明の実施の形態の再配置アドレス計算処理の手順を示すフローチャートである。本処理は、プロセッサ１３１が再配置アドレス計算部２１０を処理することによって実行される。

プロセッサ１３１は、アクセスオブジェクトの配置領域を決定する（ステップ１８０１）。具体的には、まず、Ｊａｖａヒープ領域管理テーブル２１３の生存領域終端３１０２に領域先頭３１０１のアドレスを設定する。さらに、Ｊａｖａヒープ領域１２２に格納されたアクセスオブジェクトの合計サイズを求め、未使用領域先頭３１０４に領域先頭３１０１のポインタを求められた合計サイズだけ加算されたアドレスを設定する。

プロセッサ１３１は、Ｊａｖａヒープ領域１２２に配置されたオブジェクトを順に走査し、未処理のオブジェクトが存在するか否かを判定する（ステップ１８０２）。

プロセッサ１３１は、未処理のオブジェクトが存在する場合には（ステップ１８０２の結果が「ＹＥＳ」）、処理対象のオブジェクトのオブジェクトヘッダ３４０１を参照し、オブジェクト種別を判定する（ステップ１８０３）。本発明の実施の形態では、オブジェクトの種別によって、配置する領域が決定される。具体的には、図２０の中段に示したように、生存オブジェクトは生存オブジェクト配置領域１２０１に配置し、アクセスオブジェクトはアクセスオブジェクト配置領域１２０２に配置する。

プロセッサ１３１は、処理対象のオブジェクトのオブジェクト種別が“生存”と判定された場合には（ステップ１８０３の結果が「生存」）、図２０の中段に示したように、当該オブジェクトがＪａｖａヒープ領域１２２の生存オブジェクト配置領域１２０１に配置されるように再配置アドレスを計算する（ステップ１８０５）。

なお、生存オブジェクトの再配置アドレスは、Ｊａｖａヒープ領域管理テーブル２１３の生存領域終端３１０２のポインタによって特定されるアドレスであって、再配置アドレスの計算後には、生存領域終端３１０２のポインタを生存オブジェクトのサイズだけ加算しながら再配置アドレスの計算を継続する。

プロセッサ１３１は、処理対象のオブジェクトのオブジェクト種別が“アクセス”と判定された場合には（ステップ１８０３の結果が「アクセス」）、図２０の中段に示したように、当該オブジェクトがＪａｖａヒープ領域１２２のアクセスオブジェクト配置領域１２０２に配置されるように再配置アドレスを計算する（ステップ１８０５）。

なお、アクセスオブジェクトの再配置アドレスはＪａｖａヒープ領域管理テーブル２１３の未使用領域先頭３１０４のポインタによって特定されるアドレスであって、再配置アドレスの計算後、未使用領域先頭３１０４に領域のポインタを当該アクセスオブジェクトのサイズだけ加算しながら再配置アドレスの計算を継続する。

プロセッサ１３１は、処理対象のオブジェクトのオブジェクト種別が“リーク”と判定された場合には（ステップ１８０３の結果が「リーク」）、図２０の中段に示したように、当該オブジェクトが外部ヒープ領域１１０に再配置されるように再配置アドレスを計算する（ステップ１８０４）。

なお、リークオブジェクトの再配置アドレスは外部ヒープ領域管理テーブル２１４の未使用領域先頭３１０７のポインタによって指し示されるアドレスであって、再配置アドレスの計算後、未使用領域先頭３１０７に領域のポインタを当該リークオブジェクトのサイズだけ加算しながら再配置アドレスの計算を継続する。

プロセッサ１３１は、処理対象のオブジェクトのオブジェクト種別が“デッド”と判定された場合（ステップ１８０３の結果が「デッド」）、又はステップ１８０４から１８０６の処理の終了後には、ステップ１８０２に戻り、再配置アドレス計算処理を継続する。未処理のオブジェクトが存在しない場合には（ステップ１８０２の結果が「ＮＯ」）、本処理は終了する。

ここで、オブジェクトのサイズは、通常、ページサイズと比較して小さく、１ページに複数のオブジェクトが配置される。また、ページトラップは、通常、ページ単位でのみ設定及び解除が可能である。そのため、メソッド実行中に頻繁にアクセスされるオブジェクトと、アクセス頻度の低いオブジェクトが同一ページに配置されている場合には、頻繁にアクセスされるオブジェクトにアクセスされたときに、当該ページに設定されたページトラップが解除されてしまうため、アクセス頻度の低いオブジェクトを検出するのは困難になってしまう。

そこで、以上の問題を回避するために、ステップ１８０５及びステップ１８０６の処理では、生存オブジェクトとアクセスオブジェクトとがＪａｖａヒープ領域１２２の異なる領域に配置され、極力同一ページに配置されないように再配置アドレスを計算している。また、このように再配置を繰り返すことで、Ｊａｖａヒープ領域１２２のオブジェクトは、アクセス傾向に応じて整列されていくため、メソッド実行中にアクセス頻度の低いオブジェクトの検出が容易になり、リークオブジェクトの検出精度をより向上させることができる。

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

プロセッサ１３１は、まず、外部ヒープ領域１１０に設定されたページトラップを解除し、外部ヒープ領域１１０にリークオブジェクトを配置可能な状態にする（ステップ１９０１）。

プロセッサ１３１は、Ｊａｖａヒープ領域１２２に配置されたオブジェクトを順に走査し、未処理のオブジェクトが存在するか否かを判定する（ステップ１９０２）。

プロセッサ１３１は、未処理のオブジェクトが存在する場合には（ステップ１９０２の結果が「ＹＥＳ」）、再配置アドレス計算処理によって算出された再配置アドレスに当該オブジェクトを配置する（ステップ１９０４）。ステップ１９０４の処理が終了すると、ステップ１９０２の処理を実行し、再配置実行処理を継続する。

なお、外部ヒープ領域１１０としてファイル１０５が使用され、ファイルオフセットマップ２１７を使用して主記憶と別に管理されている場合には、図９にて説明したように、Ｊａｖａヒープ領域１２２から外部ヒープ領域１１０にリークオブジェクトを再配置する。

プロセッサ１３１は、未処理のオブジェクトが存在しない場合には（ステップ１９０２の結果が「ＮＯ」）、外部ヒープ領域１１０にページトラップを設定し、メソッド実行時のリークオブジェクトへのアクセスを検知可能な状態にする（ステップ１９０３）。ステップ１９０３の処理の終了後、本処理は終了する。

ここで、ステップ１９０３の処理の終了時点におけるＪａｖａヒープ領域１２２に格納されたオブジェクト１１９と外部ヒープ領域１１０に格納されたリークオブジェクト１１２の参照関係を図３２に示す。

図３２は、本発明の実施の形態の再配置実行処理終了後におけるＪａｖａヒープ領域１２２及び外部ヒープ領域１１０に格納されたオブジェクトの状態を示す図である。

図３２は、通常のＧＣ処理によってデッドオブジェクトが回収され、さらに、オブジェクト種別が“リーク”であるリークオブジェクトがＪａｖａヒープ領域１２２から外部ヒープ領域１１０に再配置された状態を示している。このようにリークオブジェクトをＪａｖａヒープ領域１２２から外部ヒープ領域１１０に移動させることによって、Ｊａｖａヒープ領域１２２の空き領域を増やすことができる。

また、再配置後のオブジェクトの配置は、図２０の下段に示した配置となる。図２０の上段に示したようにＪａｖａヒープ領域１２２に配置されていたオブジェクトは、再配置アドレスの計算後、図２０の下段に示したように再配置され、不要なオブジェクト（デッドオブジェクト）が回収される。

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

プロセッサ１３１は、まず、Ｊａｖａヒープ領域１２２又は外部ヒープ領域１１０に格納されたオブジェクトが移動されないように、インポート処理を実行するスレッド以外の全スレッドを停止する（ステップ２５０１）。

プロセッサ１３１は、Ｊａｖａヒープ領域１２２に設定されたページトラップを解除し、Ｊａｖａヒープ領域１２２のオブジェクト１１９をアクセス可能な状態にする（ステップ２５０２）。

プロセッサ１３１は、外部ヒープ領域１１０に設定されたページトラップを解除し、外部ヒープ領域１１０のリークオブジェクト１１２にアクセス可能な状態にする（ステップ２５０３）。

プロセッサ１３１は、Ｊａｖａヒープ領域１２２に格納されたオブジェクト１１９を順に走査し、メソッド実行時にアクセスされたオブジェクトを参照している参照元オブジェクトを探索する。参照元オブジェクトが見つかった場合には、Ｊａｖａヒープ領域管理テーブル２１３の未使用領域先頭３１０４を取得し、当該オブジェクトの再配置アドレスとする。そして、参照元オブジェクトに保持される当該オブジェクトへのオブジェクト参照を取得された再配置アドレスに更新する（ステップ２５０４）。

プロセッサ１３１は、外部ヒープ領域１１０のリークオブジェクト１１２を順に走査し、アクセスされたオブジェクトを参照している参照元リークオブジェクトを探索する。参照元リークオブジェクトが見つかった場合には、ステップ２５０４の処理で取得された再配置アドレスをプロキシオブジェクト２００２が保持する未登録のオブジェクト参照に登録し、プロキシオブジェクトが保持するオブジェクト参照の識別子３６０４を取得する。そして、参照元リークオブジェクトに保持される当該オブジェクトへのオブジェクト参照に前述した識別子３６０４を記録する（ステップ２５０５）。

プロセッサ１３１は、アクセスされたオブジェクトを再配置アドレスに再配置し、Ｊａｖａヒープ領域管理テーブル２１３の未使用領域先頭３１０４のポインタを当該オブジェクトのサイズだけ加算する（ステップ２５０６）。なお、外部ヒープ領域１１０としてファイル１０５が使用され、ファイルオフセットマップ２１７を使用して主記憶と別に管理されている場合には、図９にて説明したように、外部ヒープ領域１１０からＪａｖａヒープ領域１２２にオブジェクトを再配置する。

次に、プロセッサ１３１は、参照解決処理を実行し、当該オブジェクトのオブジェクト参照を解決する（ステップ２５０７）。参照解決処理とは、アクセスされたオブジェクトが、Ｊａｖａヒープ領域１２２から外部ヒープ領域１１０に再配置される前に参照していたオブジェクトを、当該オブジェクトが外部ヒープ領域１１０からＪａｖａヒープ領域１２２に再配置された後でも正しく参照するように、当該オブジェクトのオブジェクト参照を更新する処理である。

ＧＣ処理が実行されるとＪａｖａヒープ領域１２２に格納されたオブジェクトは、再配置される。一方、本発明の実施の形態のように、外部ヒープ領域１１０をＧＣ処理の対象から除外していると、外部ヒープ領域１１０に格納されたリークオブジェクトのオブジェクト参照は更新されず、本来参照するべきオブジェクトが参照されなくなる場合がある。参照解決処理により、ＧＣ処理の実行対象でないオブジェクトのオブジェクト参照の整合性を確保することができるため、外部ヒープ領域１１０をＧＣ処理の対象から除外することができる。なお、参照解決処理の詳細については、図３４にて説明する。

図３４は、本発明の実施の形態のインポート処理における参照解決処理の手順を示すフローチャートである。

プロセッサ１３１は、処理対象オブジェクトが保持するオブジェクト参照が、プロキシオブジェクト２００２が保持するオブジェクト参照の識別子３６０４を格納しているか否かを判定する（ステップ２６０１）。なお、処理対象オブジェクトが保持するオブジェクト参照が、プロキシオブジェクト２００２が保持するオブジェクト参照の識別子３６０４を格納しているか否かは、図２９Ｂに示したように、オブジェクト参照の最下位ビットの値を検査することによって判定可能である。

プロセッサ１３１は、プロキシオブジェクト２００２に格納されたオブジェクト参照の識別子３６０４が、処理対象オブジェクトの未処理のオブジェクト参照に含まれる場合には（ステップ２６０１の結果が「ＹＥＳ」）、プロキシオブジェクト２００２の対応するオブジェクト参照からオブジェクトアドレスを取得し、未処理の対象オブジェクトのオブジェクト参照に代入する。さらに、プロキシオブジェクト２００２の対応するオブジェクト参照の値にＮＵＬＬ値を代入し、未登録状態とする（ステップ２６０２）。なお、ステップ２６０２の処理は、図２８のプロキシオブジェクト登録処理のステップ１７０４の処理と逆の処理となる。

プロセッサ１３１は、ステップ２６０２の処理の終了後、ステップ２６０１に戻り、参照解決処理を継続する。処理対象オブジェクトが保持するオブジェクト参照が、プロキシオブジェクト２００２が保持するオブジェクト参照の識別子３６０４を格納していない場合には（ステップ２６０１の結果が「ＮＯ」）、参照解決処理を終了する。

ここで、参照解決処理の終了時点におけるＪａｖａヒープ領域１２２のオブジェクト１１９と外部ヒープ領域１１０のリークオブジェクト１１２の参照関係を図３５に示す。

図３５は、本発明の実施の形態の参照解決処理終了後におけるＪａｖａヒープ領域１２２及び外部ヒープ領域１１０に格納されたオブジェクトの状態を示す図である。

図３５では、図３２に示された状態から、外部ヒープ領域１１０に格納されていたオブジェクト２７０１がアクセスされた場合を示している。このとき、インポート実行管理情報２１８のインポート範囲３００８の値には“１”が設定されている。したがって、直接アクセスされたオブジェクト２７０１と、直接アクセスされたオブジェクト２７０１のオブジェクト参照を１段辿ることによって到達可能なオブジェクト２７０２までがインポート処理によって、外部ヒープ領域１１０からＪａｖａヒープ領域１２２に再配置される。なお、直接アクセスされたオブジェクト２７０１のオブジェクト参照を２段辿らないと到達不可能なオブジェクト２７０３は、インポート処理の対象となっていないため、引き続き外部ヒープ領域１１０に格納される。

ここで、図３３のインポート処理のフローチャートの説明に戻る。

プロセッサ１３１は、外部ヒープ領域１１０にページトラップを設定し、メソッド実行時の外部ヒープ領域１１０に格納されたオブジェクトに対するアクセスを検知可能な状態にする（ステップ２５０８）。最後に、停止していたスレッドの実行を再開し（ステップ２５０９）、本処理を終了する。

インポート処理によって、外部ヒープ領域１１０からＪａｖａヒープ領域１２２にオブジェクトが再配置されると、再配置されたオブジェクトが配置してあった領域は再利用できない空き領域となる。通常、外部ヒープ領域１１０からＪａｖａヒープ領域１２２に再配置されるオブジェクトは少ないため、前述の空き領域による外部ヒープ領域１１０の使用効率の低下は大きな問題にはならない。

しかし、ＪａｖａＶＭ１０９を長時間連続して実行する場合など、外部ヒープ領域１１０の空き領域が蓄積されることによって、外部ヒープ領域１１０の使用効率の低下が無視できなくなる可能性がある。特に、外部ヒープ領域１１０に空き領域がなくなった場合には、外部ヒープ領域１１０を対象とするＧＣ処理を実行し、外部ヒープ領域１１０の使用効率を改善する必要がある。

なお、本発明の実施の形態では、外部ヒープ領域１１０を対象とするＧＣ処理が必要になった場合に、Ｊａｖａヒープ領域１２２を対象とするＧＣ処理を実行し、Ｊａｖａヒープ領域１２２を対象とするＧＣ処理の延長として外部ヒープ領域１１０を対象とするＧＣ処理を実行する。以下、図３６を参照し、図１９に示したＪａｖａヒープ領域１２２を対象とするＧＣ処理を引用しながら外部ヒープ領域１１０を対象とするＧＣ処理について説明する。

図３６は、本発明の実施の形態の外部ヒープ領域１１０を対象とするＧＣ処理の手順を示すフローチャートである。

プロセッサ１３１は、外部ヒープ領域１１０に格納されたオブジェクトについて、オブジェクトヘッダ３４０１のオブジェクト種別ビットを“デッド”の状態で初期化する（ステップ２８０１）。ステップ２８０１の処理は、図２１のステップ１４０１の処理の際に実行される。

次に、プロセッサ１３１は、外部ヒープ領域１１０に格納されたリークオブジェクト１１２についても生存オブジェクトマーキング処理を実行する（ステップ２８０２）。具体的には、外部ヒープ領域１１０に格納されたリークオブジェクト１１２については、図２６のステップ１５０２の判定処理の代わりに、当該オブジェクト参照の参照先がＪａｖａヒープ領域１２２であるか否かを判定する。ステップ２８０２の処理は、図２１のステップ１４０２の処理の際に実行される。

なお、本発明の実施の形態では、プロキシオブジェクト登録処理においてステップ１７０４の処理が実行されているため、当該オブジェクト参照の参照先がＪａｖａヒープ領域１２２であるか否かの判定は、プロキシオブジェクトのオブジェクト参照の識別子３６０４を保持しているか否かの判定と同じである。

プロセッサ１３１は、ステップ２８０２の処理で生存オブジェクトと判定されなかった外部ヒープ領域１１０に含まれるデッドオブジェクトについて、プロキシオブジェクト登録解除処理を実行する（ステップ２８０３）。プロキシオブジェクト登録解除処理を実行することによって、プロキシオブジェクト２００２を介して処理対象のデッドオブジェクトからのみ参照され、他のオブジェクトと参照関係にない生存オブジェクトをＧＣ処理によって回収することができる。なお、プロキシオブジェクト登録解除処理の詳細については、図３７にて後述する。また、デッドオブジェクトを指し示していたファイルオフセットマップ２１７のオブジェクトアドレス３７０１をＮＵＬＬ値に更新する。

図３７は、本発明の実施の形態の外部ヒープ領域１１０を対象とするＧＣ処理におけるプロキシオブジェクト登録解除処理の手順を示すフローチャートである。本処理は、図３６のステップ２８０２の処理でデッドオブジェクトと判定された外部ヒープ領域１１０に含まれるオブジェクトに対して実行される。

プロセッサ１３１は、プロキシオブジェクト２００２に格納されたオブジェクト参照の識別子が、処理対象オブジェクトの未処理のオブジェクト参照に含まれるか否かを判定する（ステップ２９０１）。

プロセッサ１３１は、プロキシオブジェクト２００２に格納されたオブジェクト参照の識別子が、処理対象オブジェクトの未処理のオブジェクト参照に含まれる場合には（ステップ２９０１の結果が「ＹＥＳ」）、プロキシオブジェクト２００２の対応するオブジェクト参照の値にＮＵＬＬ値を代入し、未登録状態とする（ステップ２９０２）。プロキシオブジェクト２００２からの参照を解除することによって、他のオブジェクトから参照されていなければ、参照を解除されたオブジェクトをＧＣ処理によって回収することができる。

プロセッサ１３１は、ステップ２９０２の処理の終了後、ステップ２９０１に戻り、参照解決処理を継続する。プロキシオブジェクト２００２に格納されたオブジェクト参照の識別子が、処理対象オブジェクトの未処理のオブジェクト参照に含まれない場合には（ステップ２９０１の結果が「ＮＯ」）、本処理を終了する。

ここで、図３６の外部ヒープ領域１１０を対象とするＧＣ処理のフローチャートの説明に戻る。

プロセッサ１３１は、ファイルオフセットマップ２１７に含まれるオブジェクトアドレス３７０１がＮＵＬＬ値であるレコードを削除し、ファイルオフセットマップ２１７をメンテナンスする（ステップ２８０４）。

プロセッサ１３１は、外部ヒープ領域１１０に含まれるリークオブジェクト１１２を対象として、再配置アドレス計算処理を実行し、オブジェクト種別が“生存”であるオブジェクトが、外部ヒープ領域１１０の領域に無駄なく再配置されるように再配置アドレスを計算する（ステップ２８０５）。ステップ２８０５の処理は、図１９のステップ１３０５の処理の際に実行される。

プロセッサ１３１は、ステップ２８０５の処理で計算された参照先オブジェクトの再配置アドレスに基づいて、各オブジェクトのオブジェクト参照の値を更新する（ステップ２８０６）。ステップ２８０６の処理は、図１９のステップ１３０６の処理の際に実行される。ステップ２８０６の処理について、図３８Ａから図３８Ｃを用いて説明する。

図３８Ａは、本発明の実施の形態のファイルオフセットマップ２１７を利用したオブジェクトの参照について説明する図である。

図３８Ａを参照すると、Ｊａｖａヒープ領域１２２に格納されたオブジェクトのオブジェクト参照３８０１が、外部ヒープ領域１１０内の仮想的なオブジェクト３８０２を参照している。すなわち、オブジェクト参照３８０１には、仮想的なオブジェクト３８０２の論理アドレスが格納されている。

また、ファイルオフセットマップ２１７は、図９に示したように、オブジェクトアドレス３７０１に仮想的なオブジェクト３８０２の論理アドレスを格納し、ファイルオフセット３７０２にファイル１０５のファイルオフセットを格納している。

仮想的なオブジェクト３８０２の実体３８０３は、ファイル１０５に記録され、ファイルオフセットマップ２１５に格納された情報に基づいて、仮想的なオブジェクト３８０２の論理アドレスに対応するファイルオフセット３７０２の位置に配置される。

図３８Ｂは、本発明の実施の形態のファイルオフセットマップ２１７を利用したオブジェクトの参照について説明する図であって、オブジェクト参照の値が更新された状態を示す図である。

図３８Ｂは、図３６のステップ２８０６の処理によって、外部ヒープ領域に格納された仮想的なオブジェクトが再配置され、論理アドレスが変更された状態である。このとき、Ｊａｖａヒープ領域１２２に含まれるオブジェクトに格納されたオブジェクト参照３８０１が更新されている。

具体的には、ステップ２８０６の処理によって、仮想的なオブジェクト３８０２は仮想的なオブジェクト３８０４として再配置され、オブジェクト参照３８０１及びオブジェクトアドレス３７０１も仮想的なオブジェクト３８０４を指し示す。なお、この段階では、ファイル１０５に格納されたオブジェクトの実体はそのままの状態である。

ここで、図３６の外部ヒープ領域１１０を対象とするＧＣ処理のフローチャートの説明に戻る。

プロセッサ１３１は、ファイル１０５の先頭から順にファイルオフセットマップ２１７のファイルオフセット３７０２に対応するオブジェクトの実体を再配置する（ステップ２８０７）。ステップ２８０７の処理を図３８Ｃを用いて説明する。ステップ２８０７の処理が終了すると、外部ヒープ領域１１０を対象とするＧＣ処理は終了する。

図３８Ｃは、本発明の実施の形態のファイルオフセットマップ２１７を利用したオブジェクトの参照について説明する図であって、オブジェクトが再配置された状態を示す図である。仮想的なオブジェクト３８０４の実体３８０３は、ステップ２８０７の処理によって、実体３８０５の位置に再配置されている。

なお、ファイルオフセットマップ２１７を利用することによって、オブジェクトに含まれるオブジェクト参照の値を変更せずにオブジェクトの実体の配置を変更することができるため、ステップ２８０７の処理はメソッド実行と並行して実行することができる。したがって、ステップ２８０１からステップ２８０６までのフェーズ１の処理はＪａｖａヒープ領域１２２に対するＧＣ処理とともに実行する必要があるが、ステップ２８０７のフェーズ２の処理については、ＧＣ処理が完了する前に全スレッドの実行を再開してもよい。

図３９は、本発明の実施の形態のＪａｖａＶＭ１０９によって出力装置１３０に出力されるＧＣ処理及びインポート処理のログの一例を示す図である。以下、出力されたログの各フィールドについて説明する。

フィールド３９０１は、当該ログについての情報を示すフィールドである。“Ｇ”は、ＧＣ処理についてのログであることを示す。また、“Ｉ”は、インポート処理についてのログであることを示している。図３９の例では、“Ｇ”によってＧＣ処理についてのログであること、“＃３”によってＪａｖａＶＭ１０９が起動してから通算３回目のＧＣ処理のログであること、“（２４．８８９）”によってＪａｖａＶＭ１０９が起動してから２４．８８９秒後に実行されたＧＣ処理のログであることを表している。

フィールド３９０２は、フィールド３９０１で示した処理に要した時間を示す。図３９の例では、当該ＧＣ処理に０．５２２８７６秒を要したことが示されている。

フィールド３９０３は、当該行に示される情報がいずれの領域に関する情報であるかを示す。具体的には、“＜ＪＨ＞”は、Ｊａｖａヒープ領域１２２についての情報、“＜ＥＨ＞”は、外部ヒープ領域１１０についての情報、“＜ＨＤ＞”は、補助記憶１０２についての情報であることを示している。

フィールド３９０４は、フィールド３９０１に示された処理によって、フィールド３９０３に示された領域の使用量の変化を示す。図３９の例では、ＧＣ処理によってＪａｖａヒープ領域１２２の使用量が“１８５２２７Ｋ”から“１２３４２７Ｋ”に変化したことを示している。

フィールド３９０５は、フィールド３９０３に示された領域のサイズを示す。図３９の例では、Ｊａｖａヒープ領域１２２のサイズが“２６２１４４Ｋ”であることを表している。

利用者は、出力されたＧＣ処理及びインポート処理のログを参照することによって、ＧＣ処理及びインポート処理の実行時間及びＪａｖａヒープ領域などの利用状況を把握することができる。

図４０は、本発明の実施の形態のＪａｖａＶＭ１０９によって出力装置１３０に出力されるオブジェクト統計情報の一例を示す図である。以下、出力されたオブジェクト統計情報の各フィールドについて説明する。

フィールド４００１は、当該統計情報についての情報を示す。“Ｇ”は、ＧＣ処理実行時に取得された統計情報であることを示す。“Ｉ”は、インポート処理実行時に取得された統計情報であることを示す。図４０の例では、“Ｇ”によってＧＣ実行時に取得された統計情報であることを示す。“＃４”によってＪａｖａＶＭ１０９が起動してから通算４回目のＧＣ処理実行時に取得された統計情報であることを示す。“（１２９．８４８）”によってＪａｖａＶＭ１０９が起動してから１２９．８４８秒後のＧＣ処理実行時に取得された統計情報であることを示している。なお、ＧＣ処理実行時やインポート処理実行時以外のタイミングで統計情報を取得する場合は、ＪａｖａＶＭ１０９が起動してから何秒後に取得した統計情報であるかを表す情報のみを出力する。

フィールド４００２は、出力された統計情報の種類を示す。“［Ｌｅａｋ］”は、リークオブジェクトに関する統計情報であることを示す。“［Ｌｅａｋ Ｓｕｓｐｉｃｉｏｎ］”は、非アクセスオブジェクトアドレステーブル２０５に登録された非アクセスオブジェクトについての統計情報であることを示す。

フィールド４００３は、統計情報が示されたオブジェクトを識別する情報を示す。具体的には、クラス名である。図４０の例では、クラス名“ｊａｖａ．ｕｓｅｒ．ＣｌａｓｓＡ”のリークオブジェクトがあることを表している。

フィールド４００４は、フィールド４００３で示されたクラス名のオブジェクトの合計サイズと、当該オブジェクトが配置された領域のサイズを順に示すフィールドである。図４０の例では、クラス名“ｊａｖａ．ｕｓｅｒ．ＣｌａｓｓＡ”のリークオブジェクトの合計サイズが９９７５８ＫＢであって、サイズが１０４８５７６ＫＢの外部ヒープ領域１１０に格納されていることを示している。

利用者は、オブジェクト統計情報を参照することによって、クラスごとにメモリリークが発生したオブジェクトを把握して、メモリリークの原因追求などに役立てることができる。また、図４１に示すオブジェクト詳細情報を参照することによって、さらに詳細にメモリの使用状況などを解析することができる。

図４１は、本発明の実施の形態のＪａｖａＶＭ１０９によって出力装置１３０に出力されるオブジェクト詳細情報の一例を示す図である。以下、出力されたオブジェクト詳細情報の各フィールドについて説明する。

フィールド４１０１及び４１０２は、図４０に示されたオブジェクト統計情報におけるフィールド４００１及び４００２と同じ内容である。

フィールド４１０３は、オブジェクト詳細情報が出力されるオブジェクトのクラス名を示す。フィールド４１０４は、オブジェクト詳細情報が出力されるオブジェクトの配置アドレスを示す。図４１の例では、アドレス“０ｘ７２ｆｆ３４４８”に配置されたクラス名“ｊａｖａ．ｕｓｅｒ．ＣｌａｓｓＡ”のオブジェクトが、リークオブジェクトであることを示している。

フィールド４１０５は、フィールド４１０４に示されたオブジェクトを参照しているオブジェクトのクラス名を示す。フィールド４１０６は、フィールド４１０４に示されたオブジェクトを参照しているオブジェクトの配置アドレスを示す。フィールド４１０７は、フィールド４１０４に示されたオブジェクトを参照するために使用されるオブジェクト参照フィールドのアドレスを示す。図４１の例では、アドレス“０ｘ７２ｆｆ３４４８”に配置されたリークオブジェクトを、アドレス“０ｘ５ａｅ２ｆ２０８”に配置されたクラス名“ｊａｖａ．ｕｓｅｒ．ＲｅｆｅｒｅｎｃｅＣｌａｓｓＡ”のオブジェクトがアドレス“０ｘ５ａｅ２ｆ２１０”のオブジェクト参照フィールドを使用して参照していることを表している。

図４２は、本発明の実施の形態のＪａｖａＶＭ１０９によって出力装置１３０に出力されるＧＣ処理の実行情報を表示する画面の一例を示す図である。

図４２の画面表示例には、領域４２０１、領域４２０２、領域４２０３及び領域４２０４が含まれている。領域４２０１の縦軸は、外部ヒープ領域１１０の使用量４２０５を示す。領域４２０２の縦軸は、Ｊａｖａヒープ領域１２２の使用量４２０６を示す。領域４２０３の縦軸は、ＧＣ処理の実行時間４２０７を示す。領域４２０４は、領域４２０１から４２０３に表示された情報の詳細を表示する領域である。

領域４２０１、領域４２０２、及び領域４２０３の横軸は、ＪａｖａＶＭ１０９が起動されてからの経過時間を示し、すべての領域で同一の時間軸を示している。このように共通の時間軸でＧＣ処理の実行情報を表示することによって、ＧＣ処理による外部ヒープ領域１１０の使用量４２０５の変化、Ｊａｖａヒープ領域１２２の使用量４２０６の変化、及びＧＣ処理に要した時間などを容易に把握することができる。

また、領域４２０１、領域４２０２、又は領域４２０３の位置を入力装置１３２から指定することによって、当該指定位置の時刻、当該時刻に対する使用量４２０５、使用量４２０６、又は実行時間４２０７の詳細を領域４２０４に表示することも可能である。

図４３は、本発明の実施の形態のＪａｖａＶＭ１０９によって出力装置１３０に出力されるＧＣ処理による領域使用量の変化を示す画面の一例を示す図である。

図４３は、図４２の領域４２０１又は領域４２０２、あるいは領域４２０１及び領域４２０２を併せた領域を示している。また、図４３に示したように、本発明の実施の形態によるＧＣ処理を実行する場合の使用量と、実行しない場合の使用量とを示してもよい。

図４３には、本発明の実施の形態のＧＣ処理を実行することによって、リークオブジェクト１１２を外部ヒープ領域１１０に再配置する場合のＪａｖａヒープ領域１２２の使用量４２０６、リークオブジェクト１１２を外部ヒープ領域１１０に再配置しない場合のＪａｖａヒープ領域１２２の使用量４３０５、及び、ＧＣ処理を実行しない場合のＪａｖａヒープ領域１２２の使用量４３０３が示されている。また、Ｊａｖａヒープ領域１２２のサイズ４３０１を重ねて表示することによって、Ｊａｖａヒープ領域１２２の残量を把握することも可能である。

利用者は、図４３に示した画面を参照することによって、Ｊａｖａヒープ領域１２２のメモリ不足エラーの発生地点を予測又は確認することができる。具体的には、ＧＣ処理を全く実行しない場合には、サイズ４３０１と使用量４３０３の交点４３０２でメモリ不足エラーが発生することを把握できる。また、リークオブジェクト１１２を外部ヒープ領域１１０に再配置しない場合には、サイズ４３０１と使用量４３０５の交点４３０４でメモリ不足エラーが発生することを把握できる。

本発明の実施の形態によれば、検出されたリークオブジェクトを外部ヒープ領域に再配置することによって、Ｊａｖａヒープ領域の空き領域を拡大することができる。

また、本発明の実施の形態によれば、メモリリークの可能性が高いと判定されたオブジェクトであっても、再びアクセスすることが可能であるため、高い堅牢性を実現することができる。

さらに、本発明の実施の形態によれば、ＧＣ処理の発生頻度を少なくすることができるため、ＧＣ処理の実行にともなうアプリケーションプログラム実行の処理速度の低下を抑えることができる。

本発明の実施の形態のＪａｖａＶＭが動作する計算機システムの構成及び入出力データを示す図である。 本発明の実施の形態であるＪａｖａＶＭにおけるメモリ管理部の構成と入出力データを示す図である。 本発明の実施の形態のリークオブジェクト検出管理情報、外部ヒープ領域管理情報、及びインポート実行管理情報の一例を示す図である。 本発明の実施の形態のＪａｖａヒープ領域を管理するためのＪａｖａヒープ領域管理テーブルの一例を示す図である。 本発明の実施の形態の外部ヒープ領域を管理するための外部ヒープ領域管理テーブルの一例を示す図である。 本発明の実施の形態の外部ヒープ領域が補助記憶に格納されたファイルに確保される場合に使用されるファイル管理テーブルの一例を示す図である。 本発明の実施の形態のリークオブジェクト検出領域及びアクセスアドレステーブルを示す図である。 本発明の実施の形態の非アクセスオブジェクトアドレステーブルの一例を示す図である。 本発明の実施の形態のオブジェクト構造を示す図である。 本発明の実施の形態のオブジェクト種別ビットの一例を示す図である。 本発明の実施の形態のファイルオフセットマップの一例を示す図である。 本発明の実施の形態のページトラップ検出部、メソッド実行部、及びリークオブジェクト検査部による処理の実行遷移を示す図である。 本発明の実施の形態のアクセス領域検査部によるアクセス領域検査処理の概要を示す図である。 非アクセスオブジェクトアドレス収集部による非アクセスオブジェクトアドレス収集処理の概要を示す図である。 本発明の実施の形態のメソッド実行処理の手順を示すフローチャートである。 本発明の実施の形態のメモリ確保処理の手順を示すフローチャートである。 本発明の実施の形態のページトラップ検出処理の手順を示すフローチャートである。 本発明の実施の形態のアクセス領域検査前処理の手順を示すフローチャートである。 本発明の実施の形態のアクセス領域検査処理の手順を示すフローチャートである。 本発明の実施の形態の非アクセスオブジェクトアドレス収集処理の手順を示すフローチャートである。 本発明の実施の形態のＧＣ処理の手順を示すフローチャートである。 本発明の実施の形態のＧＣ処理の処理過程におけるＪａｖａヒープ領域及び外部ヒープ領域の状態を示す図である。 本発明の実施の形態のオブジェクト種別判定処理の手順を示すフローチャートである。 本発明の実施の形態のオブジェクト種別判定処理の生存オブジェクトマーキング処理の終了時点におけるＪａｖａヒープ領域及び外部ヒープ領域に格納されたオブジェクトの状態を示す図である。 本発明の実施の形態のオブジェクト種別判定処理のリークオブジェクト判定処理の終了時点におけるＪａｖａヒープ領域及び外部ヒープ領域に格納されたオブジェクトの状態を示す図である。 本発明の実施の形態のオブジェクト種別判定処理のプロキシオブジェクト登録処理の終了時点におけるＪａｖａヒープ領域及び外部ヒープ領域に格納されたオブジェクトの状態を示す図である。 本発明の実施の形態のオブジェクト種別判定処理の終了時点におけるＪａｖａヒープ領域及び外部ヒープ領域に格納されたオブジェクトの状態を示す図である。 本発明の実施の形態のオブジェクト種別判定処理における生存オブジェクトマーキング処理の手順を示すフローチャートである。 本発明の実施の形態のリークオブジェクト判定処理の手順を示すフローチャートである。 本発明の実施の形態のプロキシオブジェクト登録処理の手順を示すフローチャートである。 本発明の実施の形態のプロキシオブジェクトの構造を示す図である。 本発明の実施の形態の３２ビット環境におけるオブジェクト参照によって保持する値の一例を示す図である。 本発明の実施の形態の再配置アドレス計算処理の手順を示すフローチャートである。 本発明の実施の形態の再配置実行処理の手順を示すフローチャートである。 本発明の実施の形態の再配置実行処理終了後におけるＪａｖａヒープ領域及び外部ヒープ領域に格納されたオブジェクトの状態を示す図である。 本発明の実施の形態のインポート処理の手順を示すフローチャートである。 本発明の実施の形態のインポート処理における参照解決処理の手順を示すフローチャートである。 本発明の実施の形態の参照解決処理終了後におけるＪａｖａヒープ領域及び外部ヒープ領域に格納されたオブジェクトの状態を示す図である。 本発明の実施の形態の外部ヒープ領域を対象とするＧＣ処理の手順を示すフローチャートである。 本発明の実施の形態の外部ヒープ領域を対象とするＧＣ処理におけるプロキシオブジェクト登録解除処理の手順を示すフローチャートである。 本発明の実施の形態のファイルオフセットマップを利用したオブジェクトの参照について説明する図である。 本発明の実施の形態のファイルオフセットマップを利用したオブジェクトの参照について説明する図であって、オブジェクト参照の値が更新された状態を示す図である。 本発明の実施の形態のファイルオフセットマップを利用したオブジェクトの参照について説明する図であって、オブジェクトが再配置された状態を示す図である。 本発明の実施の形態のＪａｖａＶＭによって出力装置に出力されるＧＣ処理及びインポート処理のログの一例を示す図である。 本発明の実施の形態のＪａｖａＶＭによって出力装置に出力されるオブジェクト統計情報の一例を示す図である。 本発明の実施の形態のＪａｖａＶＭによって出力装置に出力されるオブジェクト詳細情報の一例を示す図である。 本発明の実施の形態のＪａｖａＶＭによって出力装置に出力されるＧＣ処理の実行情報を表示する画面の一例を示す図である。 本発明の実施の形態のＪａｖａＶＭによって出力装置に出力されるＧＣ処理による領域使用量の変化を示す画面の一例を示す図である。

符号の説明

１０１ 計算機システム
１０２ 補助記憶
１０３ Ｊａｖａクラスファイル
１０４ Ｊａｖａソースファイル
１０５ ファイル
１０６ 設定ファイル
１０７ 主記憶
１０８ Ｊａｖａコンパイラ
１０９ ＪａｖａＶＭ
１１０ 外部ヒープ領域
１１１ ページトラップ検出部
１１２ リークオブジェクト
１１３ メソッド読み取り部
１１４ インポート実行部
１１５ ＧＣ実行部
１１６ 動的コンパイラ部
１１７ コンパイルコード格納領域
１１８ メソッド情報
１１９ オブジェクト
１２０ リークオブジェクト検出部
１２１ メモリ確保部
１２２ Ｊａｖａヒープ領域
１２３ メソッド実行部
１２４ メモリ管理部
１２５ コンパイルコード
１２６ コンパイルコード実行部
１２７ インタプリタ実行部
１２８ オペレーティングシステム
１２９ バス
１３０ 出力装置
１３１ プロセッサ
１３２ 入力装置
２０１ アクセス領域検査部
２０２ アクセスアドレステーブル
２０３ 非アクセスオブジェクトアドレス収集部
２０５ 非アクセスオブジェクトアドレステーブル
２０６ リークオブジェクト検査部
２０７ リークオブジェクト判定部
２０８ リークオブジェクト検出管理情報
２０９ オブジェクト種別判定部
２１０ 再配置アドレス計算部
２１１ オブジェクト参照更新部
２１２ 再配置実行部
２１３ Ｊａｖａヒープ領域管理テーブル
２１４ 外部ヒープ領域管理テーブル
２１５ ファイル管理テーブル
２１６ 外部ヒープ領域管理情報
２１７ ファイルオフセットマップ
２１８ インポート実行管理情報

Claims (12)

1. 計算機において実行される情報処理システムのメモリ管理方法であって、
   前記計算機は、プログラムを実行するプロセッサ、及び前記プロセッサによってアクセスされる記憶部を備え、
   前記記憶部は、
   前記プロセッサによって実行されたプログラムによって使用される記憶領域を管理するメモリ管理部、及び前記プログラムを実行することによって生成されたオブジェクトに対するアクセス情報を格納し、
   前記生成されたオブジェクトを格納する第１の記憶領域及び第２の記憶領域を含み、
   前記プロセッサは、
   前記生成されたオブジェクトを前記第１の記憶領域に格納し、
   前記第１の記憶領域に格納されたオブジェクトがアクセスされた場合には、前記アクセスされたオブジェクトの情報を前記アクセス情報に記録し、
   前記アクセス情報に基づいて、メモリリークの可能性の高いリークオブジェクトを抽出し、
   前記抽出されたリークオブジェクトを前記第２の記憶領域に移動させることを特徴とするメモリ管理方法。
2. 前記メモリ管理部は、前記生成されたオブジェクトであって、前記プログラムによる使用が終了したオブジェクトを解放するガベージコレクションを実行するガベージコレクション実行部を含み、
   前記プロセッサは、
   前記ガベージコレクションを所定のタイミングで実行し、
   前記ガベージコレクションが実行された場合に、前記抽出されたリークオブジェクトを前記第２の記憶領域に移動させることを特徴とする請求項１に記載のメモリ管理方法。
3. 前記プロセッサは、前記第２の記憶領域に格納されたオブジェクトを前記ガベージコレクションの対象外とすることを特徴とする請求項２に記載のメモリ管理方法。
4. 前記プロセッサは、前記ガベージコレクションを実行する場合に、前記第１の記憶領域に格納されたオブジェクトを前記アクセス情報に基づいて整列することを特徴とする請求項２に記載のメモリ管理方法。
5. 前記プロセッサは、
   前記第１の記憶領域に格納されたオブジェクトであって、前記プログラムの実行によってアクセスされていないオブジェクトを周期的に判定し、
   所定の回数連続してアクセスされていないと判定されたオブジェクトを前記リークオブジェクトと判定することを特徴とする請求項１に記載のメモリ管理方法。
6. 前記記憶部は、前記プロセッサによってアクセスされる主記憶部、及び、格納されたデータが前記主記憶に読み出されてから前記プロセッサにアクセスされる補助記憶部とを含み、
   前記主記憶部には、前記第１の記憶領域が作成され、
   前記補助記憶部には、前記第２の記憶領域が作成されることを特徴とする請求項１に記載のメモリ管理方法。
7. 前記プロセッサは、前記第２の記憶領域に格納されたオブジェクトがアクセスされた場合には、当該アクセスされたオブジェクトを前記第１の記憶領域に移動させることを特徴とする請求項１に記載のメモリ管理方法。
8. 前記プロセッサは、前記第１の記憶領域及び前記第２の記憶領域に格納されたオブジェクトに関する情報を出力することを特徴とする請求項１に記載のメモリ管理方法。
9. 前記プロセッサは、前記リークオブジェクトによって使用されている記憶領域のサイズを前記リークオブジェクトの識別子とともに出力することを特徴とする請求項１に記載のメモリ管理方法。
10. 前記プロセッサは、
    前記リークオブジェクトを前記第１の記憶領域から前記第２の記憶領域に移動させない場合に前記第１の記憶領域に必要な記憶容量を算出し、
    前記算出された第１の記憶領域に必要な記憶容量を出力することを特徴とする請求項１に記載のメモリ管理方法。
11. プログラムによって使用される記憶領域を管理する情報処理装置であって、
    前記プログラムを実行するプロセッサ、及び前記プロセッサによってアクセスされる記憶部を備え、
    前記記憶部は、
    前記プロセッサによって実行されたプログラムによって使用される記憶領域を管理するメモリ管理部、及び前記プログラムを実行することによって生成されたオブジェクトに対するアクセス情報を格納し、
    前記生成されたオブジェクトを格納する第１の記憶領域及び第２の記憶領域を含み、
    前記プロセッサは、
    前記生成されたオブジェクトを前記第１の記憶領域に格納し、
    前記第１の記憶領域に格納されたオブジェクトがアクセスされた場合には、前記アクセスされたオブジェクトの情報を前記アクセス情報に記録し、
    前記アクセス情報に基づいて、メモリリークの可能性の高いリークオブジェクトを抽出し、
    前記抽出されたリークオブジェクトを前記第２の記憶領域に移動させることを特徴とする情報処理装置。
12. プログラムが実行される計算機において、前記プログラムの実行によって使用される記憶領域を管理するメモリ管理プログラムであって、
    前記計算機は、前記プログラムを実行するプロセッサと、前記プログラムを実行することによって生成されたオブジェクトを格納する第１の記憶領域及び第２の記憶領域を含む記憶部とを備え、
    前記メモリ管理プログラムは、
    前記生成されたオブジェクトを前記第１の記憶領域に格納する手順と、
    前記第１の記憶領域に格納されたオブジェクトがアクセスされた場合には、前記アクセスされたオブジェクトの情報をアクセス情報として前記記憶部に記録する手順と、
    前記アクセス情報に基づいて、メモリリークの可能性の高いリークオブジェクトを抽出する手順と、
    前記抽出されたリークオブジェクトを前記第２の記憶領域に移動させる手順とを前記計算機に実行させることを特徴とするメモリ管理プログラム。

Images