WO2011104889A1 - 計算機システム、メモリ管理方法及びメモリ管理プログラム - Google Patents
計算機システム、メモリ管理方法及びメモリ管理プログラム Download PDFInfo
- Publication number
- WO2011104889A1 WO2011104889A1 PCT/JP2010/053477 JP2010053477W WO2011104889A1 WO 2011104889 A1 WO2011104889 A1 WO 2011104889A1 JP 2010053477 W JP2010053477 W JP 2010053477W WO 2011104889 A1 WO2011104889 A1 WO 2011104889A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- area
- computer system
- memory management
- processor
- class
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
Abstract
プログラムを実行するプロセッサと、メモリと、を備えた計算機システムであって、前記メモリは、ガベージコレクタによって管理される第１の領域と、ガベージコレクタによって管理されない第２の領域と、を備え、前記プロセッサは、前記プログラムを実行することによって生成されたオブジェクトを、前記第１の領域に格納し、前記第１の領域に格納されたオブジェクトの参照関係を示す情報を複数回取得し、それら取得された前記参照関係を示す情報を組み合わせた情報に基づいて、前記第２の領域に移動すべき起点となるオブジェクトを検出し、検出された前記起点となるオブジェクトを前記第２の領域に移動させることを特徴とする計算機システム。
Description
本発明は、計算機システムに関し、特に、Ｊａｖａ技術を基盤とし、内部ヒープ領域以外の記憶領域を利用する計算機システムに関する。
近年、Ｊａｖａ（登録商標）技術を基盤としたシステム（例えば金融系システム、基幹系システム）が多く現れている。Ｊａｖａ技術を基盤としたシステムでは、確保されたメモリ領域のうちの不要になった領域の解放は、Ｊａｖａ仮想マシン（以下、「ＪａｖａＶＭ」という。）に実装されたガベージコレクタによって自動的に実行される。このように、コンピュータプログラムによって不良を起こしやすいメモリ領域の解放処理を自動化することによって、複数人によるプログラム開発やプログラムの肥大化への対応が容易になっている。
このようなメモリ領域の解放処理（ガベージコレクション、以下、「ＧＣ（Ｇａｒｂａｇｅ Ｃｏｌｌｅｃｔｉｏｎ）」という。）が実行されるのは、Ｊａｖａヒープメモリの使用量が所定の閾値を超える直前である。Ｊａｖａヒープメモリとは、Ｊａｖａプログラムによって生成されたデータ（Ｊａｖａオブジェクト等）を格納するメモリ領域である。なお、ＧＣが起動した場合、Ｊａｖａプログラムによって実行中の全てのスレッドが中断し、数ミリ秒から数十秒の間、業務プログラムが停止する。
このようなＧＣのアルゴリズムとして、世代別ＧＣが多く採用されている。世代別ＧＣは、停止時間が短時間のＣｏｐｙＧＣと、停止時間が長時間のＦｕｌｌＧＣの２種類のＧＣが使い分けるものである。ＣｏｐｙＧＣは、Ｊａｖａヒープメモリが備えるＮｅｗ領域とＯＬＤ領域のうちのＮｅｗ領域についてのみＧＣを実行する。一方、ＦｕｌｌＧＣは、Ｎｅｗ領域とＯｌｄ領域の両方についてＧＣを実行する。世代別ＧＣは、状況に応じてＣｏｐｙＧＣとＦｕｌｌＧＣとを使い分けることによって、ＧＣに伴う停止時間を少なくしている。しかしながら、停止時間が長時間のＦｕｌｌＧＣの発生は避けられず、ミッションクリティカルの分野での懸念事項である。
通常、ＪａｖａＶＭは、自身が管理するヒープメモリ領域（以下、「内部ヒープ領域」という。）にＪａｖａオブジェクトを生成する。ガベージコレクタは、内部ヒープ領域に格納されたデータを解放する。
特許文献１には、内部ヒープ領域以外のメモリ領域を利用することによって、ＧＣに伴う停止時間を短縮する技術が開示されている。特許文献１に記載の技術によれば、ＧＣの対象外のヒープメモリ領域（以下、「外部ヒープ領域」という。）を設け、内部ヒープ領域に生成されたオブジェクトのうち、メモリリークの原因である可能性が高いオブジェクトを、この外部ヒープ領域に移動させている。外部ヒープ領域に移動されたオブジェクトは、それ自身が不要になった時点で、ソースコード中に記載された命令により外部ヒープ領域と共に解放される。すなわち、ＨＴＴＰセッションのような比較的長命（長寿命）のオブジェクトを外部ヒープ領域に移動させることにより、内部ヒープ領域の使用量の増加を抑えてＧＣの発生頻度を抑えることができる。このように、明示的に外部ヒープ領域にオブジェクトを生成及び解放する方法を、「明示メモリ管理方式」という。
しかしながら、この明示メモリ管理方式では、予めソースコード中に、外部ヒープ領域に生成されたオブジェクトを指定する命令及び解放する命令を明記する必要がある。そのため、既存の又は複雑化したソースコードを有するプログラムへの適用が困難である。そこで、明示メモリ管理方式において、外部ヒープ領域に生成されたオブジェクトを自動的に指定する方法が考案されている（特許文献２参照）。
特許文献２には、外部ヒープ領域を動的に解放する技術が開示されている。特許文献２に記載の技術によれば、ＧＣを実行する際に、外部ヒープ領域に格納されたオブジェクトの参照関係を調査する。調査の結果、このオブジェクトが外部ヒープ領域以外から参照されていない場合は、外部ヒープ領域ごと解放する。これにより、予めソースコード中に、外部ヒープ領域に生成されたオブジェクトを解放する命令を明記することなく、安全にメモリ領域を解放できる。
このようなメモリ領域の解放処理（ガベージコレクション、以下、「ＧＣ（Ｇａｒｂａｇｅ Ｃｏｌｌｅｃｔｉｏｎ）」という。）が実行されるのは、Ｊａｖａヒープメモリの使用量が所定の閾値を超える直前である。Ｊａｖａヒープメモリとは、Ｊａｖａプログラムによって生成されたデータ（Ｊａｖａオブジェクト等）を格納するメモリ領域である。なお、ＧＣが起動した場合、Ｊａｖａプログラムによって実行中の全てのスレッドが中断し、数ミリ秒から数十秒の間、業務プログラムが停止する。
このようなＧＣのアルゴリズムとして、世代別ＧＣが多く採用されている。世代別ＧＣは、停止時間が短時間のＣｏｐｙＧＣと、停止時間が長時間のＦｕｌｌＧＣの２種類のＧＣが使い分けるものである。ＣｏｐｙＧＣは、Ｊａｖａヒープメモリが備えるＮｅｗ領域とＯＬＤ領域のうちのＮｅｗ領域についてのみＧＣを実行する。一方、ＦｕｌｌＧＣは、Ｎｅｗ領域とＯｌｄ領域の両方についてＧＣを実行する。世代別ＧＣは、状況に応じてＣｏｐｙＧＣとＦｕｌｌＧＣとを使い分けることによって、ＧＣに伴う停止時間を少なくしている。しかしながら、停止時間が長時間のＦｕｌｌＧＣの発生は避けられず、ミッションクリティカルの分野での懸念事項である。
通常、ＪａｖａＶＭは、自身が管理するヒープメモリ領域（以下、「内部ヒープ領域」という。）にＪａｖａオブジェクトを生成する。ガベージコレクタは、内部ヒープ領域に格納されたデータを解放する。
特許文献１には、内部ヒープ領域以外のメモリ領域を利用することによって、ＧＣに伴う停止時間を短縮する技術が開示されている。特許文献１に記載の技術によれば、ＧＣの対象外のヒープメモリ領域（以下、「外部ヒープ領域」という。）を設け、内部ヒープ領域に生成されたオブジェクトのうち、メモリリークの原因である可能性が高いオブジェクトを、この外部ヒープ領域に移動させている。外部ヒープ領域に移動されたオブジェクトは、それ自身が不要になった時点で、ソースコード中に記載された命令により外部ヒープ領域と共に解放される。すなわち、ＨＴＴＰセッションのような比較的長命（長寿命）のオブジェクトを外部ヒープ領域に移動させることにより、内部ヒープ領域の使用量の増加を抑えてＧＣの発生頻度を抑えることができる。このように、明示的に外部ヒープ領域にオブジェクトを生成及び解放する方法を、「明示メモリ管理方式」という。
しかしながら、この明示メモリ管理方式では、予めソースコード中に、外部ヒープ領域に生成されたオブジェクトを指定する命令及び解放する命令を明記する必要がある。そのため、既存の又は複雑化したソースコードを有するプログラムへの適用が困難である。そこで、明示メモリ管理方式において、外部ヒープ領域に生成されたオブジェクトを自動的に指定する方法が考案されている（特許文献２参照）。
特許文献２には、外部ヒープ領域を動的に解放する技術が開示されている。特許文献２に記載の技術によれば、ＧＣを実行する際に、外部ヒープ領域に格納されたオブジェクトの参照関係を調査する。調査の結果、このオブジェクトが外部ヒープ領域以外から参照されていない場合は、外部ヒープ領域ごと解放する。これにより、予めソースコード中に、外部ヒープ領域に生成されたオブジェクトを解放する命令を明記することなく、安全にメモリ領域を解放できる。
このように、特許文献１、２に開示された技術では、内部ヒープ領域以外の外部ヒープ領域を利用することによって、ＧＣに伴う停止時間の短縮を図っている。しかしながら、内部ヒープ領域に生成されたオブジェクトのうち、どのオブジェクトを外部ヒープ領域に移動すべきかについては考慮されていなかった。そのため、外部ヒープ領域を効率的に利用できない問題があった。
本発明は、上述した問題を考慮したものであって、外部ヒープ領域に移動すべきオブジェクトを精度良く検出することによって、外部ヒープ領域を効率的に利用できる計算機システム、メモリ管理方法及びメモリ管理プログラムを提供することを目的とする。
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、プログラムを実行するプロセッサと、メモリと、を備えた計算機システムであって、前記メモリは、ガベージコレクタによって管理される第１の領域と、ガベージコレクタによって管理されない第２の領域と、を備え、前記プロセッサは、前記プログラムを実行することによって生成されたオブジェクトを、前記第１の領域に格納し、前記第１の領域に格納されたオブジェクトの参照関係を示す情報を繰り返し取得し、取得された前記参照関係を示す情報に基づいて、前記第２の領域に移動させるべき起点となるオブジェクトを検出し、検出された前記起点となるオブジェクトを前記第２の領域に移動させることを特徴とする。
本発明によれば、外部ヒープ領域（第２の領域）に移動すべきオブジェクトを精度良く検出することによって、外部ヒープ領域を効率的に利用することができる。
本発明は、上述した問題を考慮したものであって、外部ヒープ領域に移動すべきオブジェクトを精度良く検出することによって、外部ヒープ領域を効率的に利用できる計算機システム、メモリ管理方法及びメモリ管理プログラムを提供することを目的とする。
本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、プログラムを実行するプロセッサと、メモリと、を備えた計算機システムであって、前記メモリは、ガベージコレクタによって管理される第１の領域と、ガベージコレクタによって管理されない第２の領域と、を備え、前記プロセッサは、前記プログラムを実行することによって生成されたオブジェクトを、前記第１の領域に格納し、前記第１の領域に格納されたオブジェクトの参照関係を示す情報を繰り返し取得し、取得された前記参照関係を示す情報に基づいて、前記第２の領域に移動させるべき起点となるオブジェクトを検出し、検出された前記起点となるオブジェクトを前記第２の領域に移動させることを特徴とする。
本発明によれば、外部ヒープ領域（第２の領域）に移動すべきオブジェクトを精度良く検出することによって、外部ヒープ領域を効率的に利用することができる。
図１は、本発明の実施の形態の計算機システムの構成を示す図である。
図２は、所定の時点におけるＪａｖａヒープ領域内のオブジェクト間の参照関係を示す図である。
図３は、図２のケースにおけるオブジェクト情報テーブルを示す図である。
図４は、図３のテーブルを基に生成されるクラス情報テーブルを示す図である。
図５は、複数の時点におけるＪａｖａヒープ領域内のオブジェクト間の参照関係を示す図である。
図６は、図５の時刻ｔ１におけるオブジェクト情報テーブルを示す図である。
図７は、図６のテーブルを基に生成されるクラス情報テーブルを示す図である。
図８Ａ、図８Ｂ及び図８Ｃは、図５のケースにおけるオブジェクト情報テーブルを示す図である。
図９は、複数の時点におけるＪａｖａヒープ領域及び外部ヒープブロック内のオブジェクト間の参照関係を示す図である。
図１０は、参照先情報取得部の制御ロジックを示すフローチャートである。
図１１は、参照元情報取得部の制御ロジックを示すフローチャートである。
図１２は、表示画面例を示す模式図である。
図２は、所定の時点におけるＪａｖａヒープ領域内のオブジェクト間の参照関係を示す図である。
図３は、図２のケースにおけるオブジェクト情報テーブルを示す図である。
図４は、図３のテーブルを基に生成されるクラス情報テーブルを示す図である。
図５は、複数の時点におけるＪａｖａヒープ領域内のオブジェクト間の参照関係を示す図である。
図６は、図５の時刻ｔ１におけるオブジェクト情報テーブルを示す図である。
図７は、図６のテーブルを基に生成されるクラス情報テーブルを示す図である。
図８Ａ、図８Ｂ及び図８Ｃは、図５のケースにおけるオブジェクト情報テーブルを示す図である。
図９は、複数の時点におけるＪａｖａヒープ領域及び外部ヒープブロック内のオブジェクト間の参照関係を示す図である。
図１０は、参照先情報取得部の制御ロジックを示すフローチャートである。
図１１は、参照元情報取得部の制御ロジックを示すフローチャートである。
図１２は、表示画面例を示す模式図である。
以下、図面を用いて、本発明の実施の形態について説明する。
以下、本発明の実施の形態について図面に基づいて説明する。
図１は、本発明の実施の形態の計算機システム１の構成を示す図である。計算機システム１は、バス（不図示）を介して相互に接続された、補助記憶装置１０１、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０２及びメモリ１０３を備え又後述するオブジェクト情報等を表示する表示装置１２２を備える。特に、メモリ１０３は、Ｊａｖａヒープ領域（第１の記憶領域）１１７と、外部ヒープ領域（第２の記憶領域）１２０と、を備える。なお、Ｊａｖａヒープ領域は、内部ヒープ領域と同義である。
補助記憶装置１０１は、各種データを記憶するためのＨＤＤ等の記憶装置である。この補助記憶装置１０１には、Ｊａｖａプログラムを実行するためのＪａｖａソースファイル１０４、Ｊａｖａソースファイル１０４に基づいて生成されるＪａｖａクラスファイル１０５、オブジェクト情報ファイル１０６、クラス情報ファイル１０７が格納される。オブジェクト情報ファイル１０６、クラス情報ファイル１０７については後述する。
ＣＰＵ１０２は、各種処理（ここでは特にＪａｖａＶＭ１０８）を実行する演算処理装置である。ＪａｖａＶＭ１０８は、メモリ１０３の不要になったメモリ領域を動的に解放するメモリ管理機構を備える言語処理実行システムである。このＪａｖａＶＭ１０８は、プログラム読込み部１０９、プログラム実行部１１０、ＧＣ実行部１１１、参照先情報取得部１１２、外部ヒープ処理部１１３を含む。なお、このＪａｖａＶＭ１０８は、ＣＤ、ＤＶＤ等の各種記憶媒体に記憶される又はインターネット等のネットワークを介してダウンロード可能なものである。このようなＪａｖａＶＭ１０８が計算機システム１にインストールされることによって、ＣＰＵ１０２はＪａｖａＶＭ１０８を実行可能な状態になる。
プログラム読込み部１０９は、補助記憶装置１０１からＪａｖａソースファイル１０４を読み込み、このＪａｖａソースファイル１０４をコンパイルしてＪａｖａクラスファイル１０５を生成する。
プログラム実行部１１０は、Ｊａｖａクラスファイル１０５を実行することによって、Ｊａｖａプログラムを実行する。具体的には、Ｊａｖａクラスファイル１０５内のメソッドのバイトコードを読み込んで実行することによって、Ｊａｖａプログラムを実行する。
ＧＣ実行部１１１は、ＧＣを実行する、すなわちＪａｖａヒープ領域１１７に格納された不要なオブジェクト等のデータを消去することによって、Ｊａｖａヒープ領域１１７を解放する。より具体的には、このＧＣ実行部１１１は、Ｊａｖａヒープ領域１１７の空き容量が少なくなった場合に、Ｊａｖａヒープ領域１１７に格納されているオブジェクトの参照関係を示す情報を取得し、レジスタ、実行時スタック、グローバル変数等のルートセットから参照されていないオブジェクトを不要なオブジェクトとみなして消去する。
参照先情報取得部１１２は、特定の条件を満たす度に、Ｊａｖａヒープ領域１１７に格納されたオブジェクトが参照しているオブジェクト、すなわち参照先、に関する情報を繰り返し取得（即ち複数回取得）する。取得された参照先情報は、Ｊａｖａヒープ領域１１７内のオブジェクト情報テーブル１１８に出力される。なお、取得された参照先情報は、補助記憶装置１０１内のオブジェクト情報ファイル１０６にも出力可能である。
また参照先情報取得部１１２は、オブジェクト情報テーブル１１８を基に、オブジェクトの生成元のクラス毎に参照先情報をまとめたクラス情報テーブル１１９を作成する。なお、クラス毎の参照先情報は、補助記憶装置１０１のクラス情報ファイル１０７にも出力可能である。この参照先情報取得部１１２の詳細な処理内容は、図１０を用いて後述する。
外部ヒープ処理部１１３は、メモリ１０３の外部ヒープ領域１２０に対する各種処理を実行する。この外部ヒープ処理部１１３は、外部ヒープ生成部１１４、外部ヒープ解放部１１５、参照元情報取得部１１６を含む。
外部ヒープ生成部１１４は、外部ヒープ領域１２０に外部ヒープブロック１２１−１~３（以下、総称する場合、「外部ヒープブロック１２１」という。）を生成する。
本実施形態の計算機システム１は、明示メモリ管理方式を採用しており、Ｊａｖａクラスファイル１０５内で長命なオブジェクト（以下、「起点オブジェクト」という。）を指定する必要がある。指定された起点オブジェクトの生成命令が実行されると、外部ヒープ生成部１１４は外部ヒープ領域１２０に外部ヒープブロック１２１を生成する。この外部ヒープブロック１２１に、生成された起点オブジェクトが配置される。また、起点オブジェクトとの間で参照関係のあるオブジェクトは、ＧＣ実行部１１１によるＧＣ実行時に、起点オブジェクトが配置された外部ヒープブロック１２１に移動される。このようにして、起点オブジェクトが生成される度に、外部ヒープブロック１２１はその都度生成される。
外部ヒープ解放部１１５は、外部ヒープ領域１２０内の不要な外部ヒープブロック１２１を解放する。具体的には、不要になった起点オブジェクトが配置された外部ヒープブロック１２１を削除する。このとき、外部ヒープブロック１２１に配置された起点オブジェクト以外のオブジェクトは、Ｊａｖａヒープ領域１１７内やルートセットから参照されている場合は、Ｊａｖａヒープ領域１１７に移動される。他方、Ｊａｖａヒープ領域１１７内やルートセットから参照されていない場合は、起点オブジェクトと同様に削除される。
参照元情報取得部１１６は、外部ヒープ領域１２０内にある外部ヒープブロック１２１に対してバリア処理を施す。これにより、参照元情報取得部１１６は、外部ヒープブロック１２１に格納されたオブジェクトへのアクセスを検知し、同オブジェクトを参照しているオブジェクト、すなわち参照元、に関する情報を取得する。この参照元情報取得部１１６の詳細な処理内容は、図１１を用いて後述する。
Ｊａｖａヒープ領域１１７は、オブジェクト情報テーブル１１８、クラス情報テーブル１１９を格納するメモリ領域である。またＪａｖａヒープ領域１１７には、プログラム実行部１１０がプログラムを実行することによって生成されたオブジェクトが格納される。このＪａｖａヒープ領域１１７は、ＧＣ実行部１１１によるＧＣの対象のメモリ領域である。
オブジェクト情報テーブル１１８は、参照先情報取得部１１２によって取得されたオブジェクトの参照先情報を格納する。詳細は後述する。
クラス情報テーブル１１９は、参照先情報取得部１１２によって作成されたクラス毎の参照先情報を格納する。詳細は後述する。
外部ヒープ領域１２０は、Ｊａｖａヒープ領域１１７に格納されたオブジェクトのうちの起点オブジェクトを、外部ヒープブロック１２１に格納するメモリ領域である。この外部ヒープ領域１２０は、ＧＣ実行部１１１によるＧＣの非対象のメモリ領域である。
また、表示装置１２２は、参照先情報取得部１１２によって作成されたクラス毎の参照先情報に関する情報が表示される装置である。また、計算機システム１は、後述するように、クラス毎の参照関係を自動的に検出するようになっているが、この検出した参照関係から、自動的に起点オブジェクトを決定することも、表示装置１２２を介して、ユーザが起点オブジェクトを任意に選択に選択することもできるようになっている。詳細は、後述する。
図２は、所定の時点におけるＪａｖａヒープ領域１１７内のオブジェクト間の参照関係を示す図である。スタック領域２０２は、Ｊａｖａプログラムによって実行中のデータを一時的に保持するための領域である。各ノード（オブジェクト２０３~２１１等）は、Ｊａｖａヒープ領域１１７に格納されたオブジェクトを示している。
ＧＣ実行部１１１がＪａｖａヒープ領域１１７に対してＧＣを実行した場合、スタック領域２０２から直接又は間接的に参照されているオブジェクト（記号が付与されていないオブジェクト）は、必要なオブジェクトと判断される。一方、スタック領域２０２から直接又は間接的に参照されていないオブジェクト２０３~２１１は、不必要なオブジェクトと判断される。不必要と判断されたオブジェクト２０３~２１１は、メモリリークの原因となる可能性が高い。そのため、これらオブジェクト２０３~２１１をプロファイリングする必要がある。
そこで、本実施形態の計算機システム１では、以下に説明する方法により、オブジェクト２０３~２１１から外部ヒープ領域１２０に移動すべき起点オブジェクトを検出し、検出された起点オブジェクトを外部ヒープ領域１２０に移動させる。
まず、参照先情報取得部１１２は、Ｊａｖａヒープ領域１１７に格納されたオブジェクト２０３~２１１の参照先情報を取得する。取得された参照先情報は、Ｊａｖａヒープ領域１１７内のオブジェクト情報テーブル１１８に出力される。
図３は、図２のケースにおけるオブジェクト情報テーブル１１８を示す図である。このオブジェクト情報テーブル１１８は、図２のＪａｖａヒープ領域１１７に格納されたオブジェクトの参照先情報を管理している。
オブジェクト情報テーブル１１８は、オブジェクト名３０１、クラス名３０２、参照先３０３及びサイズ３０４の各項目を含むレコードを保持する。
オブジェクト名３０１には、上記により不必要と判断されたオブジェクトの名前が格納される。クラス名３０２には、オブジェクトの生成元のクラスの名前が格納される。参照先３０３には、オブジェクトの参照先のオブジェクトの名前が格納される。サイズ３０４には、オブジェクト名３０１のオブジェクト単体のサイズが格納される。
本例では、オブジェクト名３０１には、不必要と判断されたオブジェクト２０３~２１１の名前であるｘ１~ｚ３が格納される。クラス名３０２には、オブジェクトｘ１~ｘ３の生成元のクラスの名前Ｘ、オブジェクトｙ１~ｙ３の生成元のクラスの名前Ｙ、オブジェクトｚ１~ｚ３の生成元のクラスの名前Ｚが格納される。参照先３０３には、オブジェクトｘ１の参照先のオブジェクトの名前（ｚ１、ｚ２、ｚ３）、オブジェクトｘ２の参照先のオブジェクトの名前（ｚ１、ｚ２）、オブジェクトｘ３の参照先のオブジェクトの名前（ｚ１、ｚ２）が格納される。なお、オブジェクトｙ１~ｚ３は他のオブジェクトを参照していないため、参照先３０３は空欄である。サイズ３０４には、オブジェクトｘ１~ｘ３のサイズとして１、オブジェクトｙ１~ｙ３のサイズとして２、オブジェクトｚ１~ｚ３のサイズとして３が格納される。
次に、参照先情報取得部１１２は、オブジェクト情報テーブル１１８を基に、オブジェクトの生成元のクラス毎の参照先情報を生成する（即ちオブジェクト情報テーブル１１８を組み合わせ、オブジェクト生成元のクラス毎の参照先を示す情報を生成する）。生成されたクラス毎の参照先情報は、Ｊａｖａヒープ領域１１７内のクラス情報テーブル１１９に出力される。
具体的には、参照先情報取得部１１２は、まずオブジェクト情報テーブル１１８に格納されたオブジェクトの生成元のクラスＸ、Ｙ、Ｚを全て抽出する。その後、抽出された各々のクラスの総オブジェクトサイズ（以下、「加重」という。）を算出する。加重とは、抽出されたクラスから生成された全てのオブジェクトのサイズと、そのオブジェクトの参照先の全てのオブジェクトのサイズと、を全て加算することによって得られる値である。その後、各々のクラスの加重をクラス情報テーブル１１９に出力する。
図４は、図３のテーブルを基に生成されるクラス情報テーブル１１９を示す図である。 クラス情報テーブル１１９は、クラス名４０１、サイズ４０２及び加重４０３の各項目を含むレコードを保持する。
クラス名４０１には、クラスの名前が格納される。サイズ４０２には、クラス単体のサイズが格納される。加重４０３には、各々のクラスの加重が格納される。
本例では、クラス名４０１には、抽出されたクラスの名前であるＸ、Ｙ、Ｚが格納される。サイズ４０２には、各クラスのクラス単体のサイズ１、２、３が格納される。加重４０３には、各々のクラスＸ、Ｙ、Ｚの加重が格納される。例えばクラスＸの加重は、クラスＸから生成された全てのオブジェクトｘ１、ｘ２、ｘ３のサイズと、各々のオブジェクトｘ１、ｘ２、ｘ３の参照先のオブジェクト（ｚ１、ｚ２、ｚ３）、（ｚ１、ｚ２）、（ｚ１、ｚ２）のサイズと、を全て加算して得られる２４である。クラスＹの加重は、クラスＹから生成された全てのオブジェクトｙ１、ｙ２、ｙ３のサイズを全て加算して得られる６である。クラスＺの加重は、クラスＺから生成された全てのオブジェクトｚ１（３個）、ｚ２（３個）、ｚ３のサイズを全て加算して得られる２１である。
ここで、加重が大きいクラスほど、メモリリークの原因となるオブジェクト群の起点であると判定できる。そのため、このクラス情報テーブル１１９のケースでは、クラスＸから生成されたオブジェクトｘ１、ｘ２、ｘ３を起点オブジェクトとして検出することができる。なお、加重が予め定められた閾値（例えば２０）を超えた１又は２以上のクラス（例えばクラスＸ、Ｚ）から生成されたオブジェクトｘ１、ｘ２、ｘ３、ｚ１、ｚ２を起点オブジェクトとして検出してもよい。
図５は、複数の時点におけるＪａｖａヒープ領域１１７内のオブジェクト間の参照関係を示す図である。
図２は、所定の時点におけるＪａｖａヒープ領域１１７内のオブジェクト間の参照関係を示した。一方、この図５では、スレッド実行中の時刻ｔ１、ｔ２、ｔ３において、Ｊａｖａヒープ領域１１７の状態がそれぞれ状態５０１、５０２、５０３の順に経時変化する場合のオブジェクト間の参照関係を示している。
状態５０１では、オブジェクト５０４の参照先はオブジェクト５１０である。状態５０２では、オブジェクト５０４の参照先はオブジェクト５０５である。状態５０３では、オブジェクト５０４の参照先はオブジェクト５０６である。
プログラム実行部１１０により実行されるプログラムによっては、図５のようにオブジェクトの参照先が経時変化する場合がある。図５に示す例では、最上位の参照元であると判定できるオブジェクト５０４が、起点オブジェクトとして相応しい。オブジェクト５０４が起点オブジェクトであることを検出することができれば、生成する外部ヒープブロック１２１は一つのみで済む。
図６は、図５の時刻ｔ１におけるオブジェクト情報テーブル１１８を示す図である。このオブジェクト情報テーブル１１８は、図５の時刻ｔ１においてＪａｖａヒープ領域１１７に格納されたオブジェクトの参照先情報を管理している。
図６に示すオブジェクト情報テーブル１１８では、オブジェクトａ１（図５のオブジェクト５０４）の参照先のオブジェクトはオブジェクトｄ１（図５のオブジェクト５１０）のみである。そのため、このオブジェクト情報テーブル１１８には、図５の時刻ｔ２、ｔ３のように、オブジェクト５０４の参照先のオブジェクトがオブジェクト５０５、５０６であるケースが反映されていない。
図７は、図６のテーブルを基に生成されるクラス情報テーブル１１９を示す図である。クラスＡの加重は、クラスＡから生成されたオブジェクトａ１のサイズと、このオブジェクトａ１の参照先のオブジェクトｄ１のサイズと、を全て加算して得られる５である。クラスＢの加重は、クラスＢから生成された全てのオブジェクトｂ１、ｂ２のサイズと、各々のオブジェクトｂ１、ｂ２の参照先のオブジェクト（ｃ１、ｃ２）、（ｃ３）のサイズと、を全て加算して得られる１３である。クラスＣの加重は、クラスＣから生成された全てのオブジェクトｃ１、ｃ２、ｃ３のサイズを全て加算して得られる９である。クラスＤの加重は、クラスＤから生成されたオブジェクトｄ１のサイズの４である。
図６のテーブルを基に生成されたクラス情報テーブル１１９では、加重が最も大きいクラスはクラスＢである。そのため、クラスＢから生成されたオブジェクトｂ１、ｂ２（図５のオブジェクト５０５、５０６）を起点オブジェクトとして検出することができる。言い換えると、上記のように最上位の参照元であると判断できるオブジェクトａ１（図５のオブジェクト５０４）を起点オブジェクトとして検出できない。
このような場合に、最上位の参照元であると判断できるオブジェクト５０４を起点オブジェクトとして検出するために、本実施形態の計算機システム１では、参照先情報取得部１１２は、特定の条件を満たす度に（例えば一定時間毎に）、Ｊａｖａヒープ領域１１７に格納されたオブジェクト５０４~５１０の参照先情報を繰り返し取得する。取得された参照先情報は、オブジェクト情報テーブル１１８に出力される。
図８Ａ、図８Ｂ及び図８Ｃは、図５のケースにおけるオブジェクト情報テーブル１１８を示す図である。図８Ａ、図８Ｂ及び図８Ｃは、それぞれスレッド開始からΔｔ毎の時刻ｔ１、ｔ２、ｔ３におけるオブジェクトの参照先情報を管理している。
図８Ａに示すオブジェクト情報テーブル１１８では、図５の状態５０１におけるオブジェクトの参照先情報が管理されている。オブジェクトａ１（図５のオブジェクト５０４）の参照先のオブジェクトは、オブジェクトｄ１（図５のオブジェクト５１０）である。図８Ｂに示すオブジェクト情報テーブル１１８では、図５の状態５０２におけるオブジェクトａ１（５０４）の参照先のオブジェクトｂ１（５０５）が、オブジェクトａ１の参照先に追加されている。図８Ｃに示すオブジェクト情報テーブル１１８では、図５の状態５０３におけるオブジェクトａ１（５０４）の参照先のオブジェクトｂ２（５０５）が、オブジェクトａ１の参照先に追加されている。
以上のように、参照先情報取得部１１２は、特定の条件を満たす度に、オブジェクトの参照先情報を繰り返し取得するとともに、取得された参照先情報をオブジェクト情報テーブル１１８に追加している。このようなオブジェクト情報テーブル１１８を基に生成されたクラス情報テーブル１１９（不図示）を用いることによって、最上位の参照元であると判断できるオブジェクトａ１（図５のオブジェクト５０４）を起点オブジェクトとして検出することができる。
続いて、起点オブジェクトとして相応しくないオブジェクトが起点オブジェクトとして検出され、外部ヒープブロック１２１に移動された場合の対応処理について説明する。
図９は、複数の時点におけるＪａｖａヒープ領域１１７及び外部ヒープブロック１２１内のオブジェクト間の参照関係を示す図である。この図９では、スレッド実行中の時刻ｔ４、ｔ５、ｔ６において、Ｊａｖａヒープ領域１１７及び外部ヒープブロック１２１の状態がそれぞれ状態９０１、９０２、９０３の順に経時変化する場合のオブジェクト間の参照関係を示している。
状態９０１では、オブジェクト９０８、９０９が起点オブジェクトとして検出され、それぞれ外部ヒープブロック１２１−１、１２１−２に移動されている。状態９０２では、オブジェクト９０７はオブジェクト９０８を参照している。状態９０３では、オブジェクト９０７はオブジェクト９０９を参照している。
図９に示す例では、最上位の参照元であると判定できるオブジェクト９０７が、起点オブジェクトとして相応しい。オブジェクト９０７が起点オブジェクトであることを検出することができれば、生成する外部ヒープブロック１２１は一つのみで済む。言い換えると、オブジェクト９０８、９０９は最適な起点オブジェクトとは言えない。そのため、以下に示す図１０、図１１、特に図１１の制御ロジックにより、本実施形態の計算機システム１では、最適な起点オブジェクトとしてオブジェクト９０７を検出する。
図１０は、参照先情報取得部１１２の制御ロジックを示すフローチャートである。
まずステップ１００１では、参照先情報取得部１１２は、特定条件を満たすまで待機する（ステップ１００１）。特定条件とは、一定時間経過する又はプログラム実行部１１０がプログラム実行中にオブジェクトの参照関係が変化する等の条件である。特定条件を満たした場合（ステップ１００２でＹＥＳ）、ステップ１００３に進む。特定条件を満たさずにスレッドが終了した場合には（ステップ１００２でＮＯ）、処理を終了する。
ステップ１００３に進んだ場合、参照先情報取得部１１２は、Ｊａｖａヒープ領域１１７内に未処理のオブジェクトが存在するか否かを調査する（ステップ１００３）。未処理のオブジェクトが存在する場合には（ステップ１００４でＹＥＳ）、ステップ１００５に進み、参照先情報取得部１１２は、未処理のオブジェクトの状態を処理済みに変更し、そのオブジェクトの参照先のオブジェクトに関する情報を調査・取得する（ステップ１００５）。その後ステップ１００６では、参照先情報取得部１１２は、取得された参照先のオブジェクトに関する情報がオブジェクト情報テーブル１１８に未登録か又は登録済みかを調査する（ステップ１００６）。未登録であって登録が必要な場合には（ステップ１００７でＹＥＳ）、ステップ１００８に進み、参照先情報取得部１１２は、参照先のオブジェクトに関する情報をオブジェクト情報テーブル１１８に登録する（ステップ１００８）。その後、ステップ１００３に戻って、参照先情報取得部１１２は、次の未処理のオブジェクトが存在するか調査する。一方、登録済みであって登録が不要な場合には（ステップ１００７でＮＯ）、ステップ１００３に戻る。なお、ステップ１００４において未処理のオブジェクトが存在しない、すなわち全てのオブジェクトの処理が完了した又は処理すべきオブジェクトが存在しない場合には（ステップ１００４でＮＯ）、ステップ１００１に戻って、参照先情報取得部１１２は、再び待機状態になる。
以上に示す制御ロジックにより、参照先情報取得部１１２は、特定条件を満たす度に、Ｊａｖａヒープ領域１１７内の全ての未処理のオブジェクトの参照先情報を繰り返し取得し、オブジェクト情報テーブル１１８に登録する。
図１１は、参照元情報取得部１１６の制御ロジックを示すフローチャートである。
まずステップ１１０１では、参照元情報取得部１１６は、現在のオブジェクト情報テーブル１１８を基に各クラスの加重を算出し、クラス情報テーブル１１９に登録する（ステップ１１０１）。次にステップ１１０２では、参照元情報取得部１１６は、クラス情報テーブル１１９を参照して、加重が閾値以上のクラスが存在するか否かを判定する（ステップ１１０２）。加重が閾値以上のクラスが存在する場合には（ステップ１１０２でＹＥＳ）、ステップ１１０３に進む。一方、加重が閾値以上のクラスが存在しない場合には（ステップ１１０２でＮＯ）、処理を終了する。
ステップ１１０３に進んだ場合、参照元情報取得部１１６は、加重が閾値以上のクラスから生成されるオブジェクト、つまり起点オブジェクトを格納する外部ヒープ領域１２０（外部ヒープブロック１２１）にバリア処理を施す（ステップ１１０３）。ここでいうバリア処理とは、起点オブジェクトに対する他のオブジェクトのアクセス（図９の場合にはオブジェクト９０８、９０９に対するオブジェクト９０７からのアクセス）を検知するために施される処理である。
その後ステップ１１０４では、参照元情報取得部１１６は、バリア済み領域に対する他のオブジェクトのアクセスがあったか否かを検出する（ステップ１１０４）。他のオブジェクトのアクセスがあった場合には（ステップ１１０４でＹＥＳ）、ステップ１１０５に進んで、参照元情報取得部１１６は、アクセスしたオブジェクト、すなわち参照元のオブジェクトに関する情報を、アクセスされたオブジェクトに記録する（ステップ１１０５）。ここでは、アクセスが検知されるとＪａｖａＶＭ１０８へ検知信号が送信されるので、アクセスされたオブジェクト内に参照元のオブジェクトに関する情報を記録することができる。一方、他のオブジェクトのアクセスがない場合には（ステップ１１０４でＮＯ）、スレッド実行中は（ステップ１１０６でＮＯ）、ステップ１１０２に戻って処理を繰り返す。スレッドが終了した場合には（ステップ１１０６でＹＥＳ）、参照元情報取得部１１６は、ステップ１１０５で記録された参照元のオブジェクトに関する情報を基に、オブジェクト情報テーブル１１８を更新し（ステップ１１０８）、処理を終了する。
以上に示す制御ロジックにより、参照元情報取得部１１６は、起点オブジェクトが格納された外部ヒープ領域１２０にアクセスするオブジェクトを全て抽出し、抽出されたオブジェクトに関する情報を基に、オブジェクト情報テーブル１１８を起点オブジェクトの検出に最適なテーブルに更新することができる。
以上の処理により得られた結果に基づいて、起点となるオブジェクトを、計算機システム１が自動に若しくはユーザが手動で指定することができる。自動で指定する場合は、例えば、加重値が最も大であるクラスのオブジェクトを起点オブジェクトとして指定するようにしてもよい。手動で指定する場合は、以下に説明する表示装置１２２の画面を介して指定してもよい。
表示装置１２２に表示される画面の例について説明する。図１２は、表示装置１２２に表示される画面例を示す。画面上には、各クラス１２３に関してインスタンス数１２４、サイズ値１２５及び加重値１２６といった情報を一覧表示するとともに、起点オブジェックトの生成場所１２７を表示するようになっている。
図１２において、インスタンス数１２４、サイズ値１２５及び加重値１２６といった情報は、加重値の大きさに応じて大であるものを昇順で表示している。生成場所１２７は、クラス毎のオブジェクトを内部ヒープブロック或いは外部ヒープブロックとするかをユーザが選択可能なチェックボックスが表示される。即ち加重値が最大であるクラスＡを起点オブジェクトとして外部ヒープブロックに設ける場合、ユーザ操作により生成場所１２７の「起点（外部）」にチェックボックスを入れることで、指定を行うことができるようになっている。クラスＢ及びＣは、起点オブジェクトとしないため、「通常（内部）」にチェックボックスを入れる。）。
以上説明してきた本実施形態の計算機システム１によれば、外部ヒープ領域に移動すべき起点オブジェクトを精度良く検出し、外部ヒープ領域を効率的に利用することができる。これに伴い、ＧＣの発生頻度を抑えることもできる。また、図９の時刻ｔ４のようなケースを防ぐことによって、外部ヒープブロックの数及び生成・解放に係るコストを抑えることができる。また、表示装置１２２を介してクラス毎の加重等をユーザに提供することができ、その加重に基づいてユーザが起点オブジェクトを任意に指定することもでき、起点オブジェクトの指定に関する利便性を向上させることができる。
なお、計算機システム１のテスト環境において、最適な起点オブジェクトを検出するまでにオブジェクト情報テーブル１１８及びクラス情報テーブル１１９に格納された各種情報を、補助記憶装置１０１内のオブジェクト情報ファイル１０６及びクラス情報ファイル１０７に蓄積させておくことが好ましい。この場合には、計算機システム１の本番環境において、オブジェクト情報ファイル１０６及びクラス情報ファイル１０７を用いることによって再度オブジェクト情報テーブル１１８及びクラス情報テーブル１１９を生成することによるオーバヘッドを起こすことなく、最適な起点オブジェクトを検出することができる。
以下、本発明の実施の形態について図面に基づいて説明する。
図１は、本発明の実施の形態の計算機システム１の構成を示す図である。計算機システム１は、バス（不図示）を介して相互に接続された、補助記憶装置１０１、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０２及びメモリ１０３を備え又後述するオブジェクト情報等を表示する表示装置１２２を備える。特に、メモリ１０３は、Ｊａｖａヒープ領域（第１の記憶領域）１１７と、外部ヒープ領域（第２の記憶領域）１２０と、を備える。なお、Ｊａｖａヒープ領域は、内部ヒープ領域と同義である。
補助記憶装置１０１は、各種データを記憶するためのＨＤＤ等の記憶装置である。この補助記憶装置１０１には、Ｊａｖａプログラムを実行するためのＪａｖａソースファイル１０４、Ｊａｖａソースファイル１０４に基づいて生成されるＪａｖａクラスファイル１０５、オブジェクト情報ファイル１０６、クラス情報ファイル１０７が格納される。オブジェクト情報ファイル１０６、クラス情報ファイル１０７については後述する。
ＣＰＵ１０２は、各種処理（ここでは特にＪａｖａＶＭ１０８）を実行する演算処理装置である。ＪａｖａＶＭ１０８は、メモリ１０３の不要になったメモリ領域を動的に解放するメモリ管理機構を備える言語処理実行システムである。このＪａｖａＶＭ１０８は、プログラム読込み部１０９、プログラム実行部１１０、ＧＣ実行部１１１、参照先情報取得部１１２、外部ヒープ処理部１１３を含む。なお、このＪａｖａＶＭ１０８は、ＣＤ、ＤＶＤ等の各種記憶媒体に記憶される又はインターネット等のネットワークを介してダウンロード可能なものである。このようなＪａｖａＶＭ１０８が計算機システム１にインストールされることによって、ＣＰＵ１０２はＪａｖａＶＭ１０８を実行可能な状態になる。
プログラム読込み部１０９は、補助記憶装置１０１からＪａｖａソースファイル１０４を読み込み、このＪａｖａソースファイル１０４をコンパイルしてＪａｖａクラスファイル１０５を生成する。
プログラム実行部１１０は、Ｊａｖａクラスファイル１０５を実行することによって、Ｊａｖａプログラムを実行する。具体的には、Ｊａｖａクラスファイル１０５内のメソッドのバイトコードを読み込んで実行することによって、Ｊａｖａプログラムを実行する。
ＧＣ実行部１１１は、ＧＣを実行する、すなわちＪａｖａヒープ領域１１７に格納された不要なオブジェクト等のデータを消去することによって、Ｊａｖａヒープ領域１１７を解放する。より具体的には、このＧＣ実行部１１１は、Ｊａｖａヒープ領域１１７の空き容量が少なくなった場合に、Ｊａｖａヒープ領域１１７に格納されているオブジェクトの参照関係を示す情報を取得し、レジスタ、実行時スタック、グローバル変数等のルートセットから参照されていないオブジェクトを不要なオブジェクトとみなして消去する。
参照先情報取得部１１２は、特定の条件を満たす度に、Ｊａｖａヒープ領域１１７に格納されたオブジェクトが参照しているオブジェクト、すなわち参照先、に関する情報を繰り返し取得（即ち複数回取得）する。取得された参照先情報は、Ｊａｖａヒープ領域１１７内のオブジェクト情報テーブル１１８に出力される。なお、取得された参照先情報は、補助記憶装置１０１内のオブジェクト情報ファイル１０６にも出力可能である。
また参照先情報取得部１１２は、オブジェクト情報テーブル１１８を基に、オブジェクトの生成元のクラス毎に参照先情報をまとめたクラス情報テーブル１１９を作成する。なお、クラス毎の参照先情報は、補助記憶装置１０１のクラス情報ファイル１０７にも出力可能である。この参照先情報取得部１１２の詳細な処理内容は、図１０を用いて後述する。
外部ヒープ処理部１１３は、メモリ１０３の外部ヒープ領域１２０に対する各種処理を実行する。この外部ヒープ処理部１１３は、外部ヒープ生成部１１４、外部ヒープ解放部１１５、参照元情報取得部１１６を含む。
外部ヒープ生成部１１４は、外部ヒープ領域１２０に外部ヒープブロック１２１−１~３（以下、総称する場合、「外部ヒープブロック１２１」という。）を生成する。
本実施形態の計算機システム１は、明示メモリ管理方式を採用しており、Ｊａｖａクラスファイル１０５内で長命なオブジェクト（以下、「起点オブジェクト」という。）を指定する必要がある。指定された起点オブジェクトの生成命令が実行されると、外部ヒープ生成部１１４は外部ヒープ領域１２０に外部ヒープブロック１２１を生成する。この外部ヒープブロック１２１に、生成された起点オブジェクトが配置される。また、起点オブジェクトとの間で参照関係のあるオブジェクトは、ＧＣ実行部１１１によるＧＣ実行時に、起点オブジェクトが配置された外部ヒープブロック１２１に移動される。このようにして、起点オブジェクトが生成される度に、外部ヒープブロック１２１はその都度生成される。
外部ヒープ解放部１１５は、外部ヒープ領域１２０内の不要な外部ヒープブロック１２１を解放する。具体的には、不要になった起点オブジェクトが配置された外部ヒープブロック１２１を削除する。このとき、外部ヒープブロック１２１に配置された起点オブジェクト以外のオブジェクトは、Ｊａｖａヒープ領域１１７内やルートセットから参照されている場合は、Ｊａｖａヒープ領域１１７に移動される。他方、Ｊａｖａヒープ領域１１７内やルートセットから参照されていない場合は、起点オブジェクトと同様に削除される。
参照元情報取得部１１６は、外部ヒープ領域１２０内にある外部ヒープブロック１２１に対してバリア処理を施す。これにより、参照元情報取得部１１６は、外部ヒープブロック１２１に格納されたオブジェクトへのアクセスを検知し、同オブジェクトを参照しているオブジェクト、すなわち参照元、に関する情報を取得する。この参照元情報取得部１１６の詳細な処理内容は、図１１を用いて後述する。
Ｊａｖａヒープ領域１１７は、オブジェクト情報テーブル１１８、クラス情報テーブル１１９を格納するメモリ領域である。またＪａｖａヒープ領域１１７には、プログラム実行部１１０がプログラムを実行することによって生成されたオブジェクトが格納される。このＪａｖａヒープ領域１１７は、ＧＣ実行部１１１によるＧＣの対象のメモリ領域である。
オブジェクト情報テーブル１１８は、参照先情報取得部１１２によって取得されたオブジェクトの参照先情報を格納する。詳細は後述する。
クラス情報テーブル１１９は、参照先情報取得部１１２によって作成されたクラス毎の参照先情報を格納する。詳細は後述する。
外部ヒープ領域１２０は、Ｊａｖａヒープ領域１１７に格納されたオブジェクトのうちの起点オブジェクトを、外部ヒープブロック１２１に格納するメモリ領域である。この外部ヒープ領域１２０は、ＧＣ実行部１１１によるＧＣの非対象のメモリ領域である。
また、表示装置１２２は、参照先情報取得部１１２によって作成されたクラス毎の参照先情報に関する情報が表示される装置である。また、計算機システム１は、後述するように、クラス毎の参照関係を自動的に検出するようになっているが、この検出した参照関係から、自動的に起点オブジェクトを決定することも、表示装置１２２を介して、ユーザが起点オブジェクトを任意に選択に選択することもできるようになっている。詳細は、後述する。
図２は、所定の時点におけるＪａｖａヒープ領域１１７内のオブジェクト間の参照関係を示す図である。スタック領域２０２は、Ｊａｖａプログラムによって実行中のデータを一時的に保持するための領域である。各ノード（オブジェクト２０３~２１１等）は、Ｊａｖａヒープ領域１１７に格納されたオブジェクトを示している。
ＧＣ実行部１１１がＪａｖａヒープ領域１１７に対してＧＣを実行した場合、スタック領域２０２から直接又は間接的に参照されているオブジェクト（記号が付与されていないオブジェクト）は、必要なオブジェクトと判断される。一方、スタック領域２０２から直接又は間接的に参照されていないオブジェクト２０３~２１１は、不必要なオブジェクトと判断される。不必要と判断されたオブジェクト２０３~２１１は、メモリリークの原因となる可能性が高い。そのため、これらオブジェクト２０３~２１１をプロファイリングする必要がある。
そこで、本実施形態の計算機システム１では、以下に説明する方法により、オブジェクト２０３~２１１から外部ヒープ領域１２０に移動すべき起点オブジェクトを検出し、検出された起点オブジェクトを外部ヒープ領域１２０に移動させる。
まず、参照先情報取得部１１２は、Ｊａｖａヒープ領域１１７に格納されたオブジェクト２０３~２１１の参照先情報を取得する。取得された参照先情報は、Ｊａｖａヒープ領域１１７内のオブジェクト情報テーブル１１８に出力される。
図３は、図２のケースにおけるオブジェクト情報テーブル１１８を示す図である。このオブジェクト情報テーブル１１８は、図２のＪａｖａヒープ領域１１７に格納されたオブジェクトの参照先情報を管理している。
オブジェクト情報テーブル１１８は、オブジェクト名３０１、クラス名３０２、参照先３０３及びサイズ３０４の各項目を含むレコードを保持する。
オブジェクト名３０１には、上記により不必要と判断されたオブジェクトの名前が格納される。クラス名３０２には、オブジェクトの生成元のクラスの名前が格納される。参照先３０３には、オブジェクトの参照先のオブジェクトの名前が格納される。サイズ３０４には、オブジェクト名３０１のオブジェクト単体のサイズが格納される。
本例では、オブジェクト名３０１には、不必要と判断されたオブジェクト２０３~２１１の名前であるｘ１~ｚ３が格納される。クラス名３０２には、オブジェクトｘ１~ｘ３の生成元のクラスの名前Ｘ、オブジェクトｙ１~ｙ３の生成元のクラスの名前Ｙ、オブジェクトｚ１~ｚ３の生成元のクラスの名前Ｚが格納される。参照先３０３には、オブジェクトｘ１の参照先のオブジェクトの名前（ｚ１、ｚ２、ｚ３）、オブジェクトｘ２の参照先のオブジェクトの名前（ｚ１、ｚ２）、オブジェクトｘ３の参照先のオブジェクトの名前（ｚ１、ｚ２）が格納される。なお、オブジェクトｙ１~ｚ３は他のオブジェクトを参照していないため、参照先３０３は空欄である。サイズ３０４には、オブジェクトｘ１~ｘ３のサイズとして１、オブジェクトｙ１~ｙ３のサイズとして２、オブジェクトｚ１~ｚ３のサイズとして３が格納される。
次に、参照先情報取得部１１２は、オブジェクト情報テーブル１１８を基に、オブジェクトの生成元のクラス毎の参照先情報を生成する（即ちオブジェクト情報テーブル１１８を組み合わせ、オブジェクト生成元のクラス毎の参照先を示す情報を生成する）。生成されたクラス毎の参照先情報は、Ｊａｖａヒープ領域１１７内のクラス情報テーブル１１９に出力される。
具体的には、参照先情報取得部１１２は、まずオブジェクト情報テーブル１１８に格納されたオブジェクトの生成元のクラスＸ、Ｙ、Ｚを全て抽出する。その後、抽出された各々のクラスの総オブジェクトサイズ（以下、「加重」という。）を算出する。加重とは、抽出されたクラスから生成された全てのオブジェクトのサイズと、そのオブジェクトの参照先の全てのオブジェクトのサイズと、を全て加算することによって得られる値である。その後、各々のクラスの加重をクラス情報テーブル１１９に出力する。
図４は、図３のテーブルを基に生成されるクラス情報テーブル１１９を示す図である。 クラス情報テーブル１１９は、クラス名４０１、サイズ４０２及び加重４０３の各項目を含むレコードを保持する。
クラス名４０１には、クラスの名前が格納される。サイズ４０２には、クラス単体のサイズが格納される。加重４０３には、各々のクラスの加重が格納される。
本例では、クラス名４０１には、抽出されたクラスの名前であるＸ、Ｙ、Ｚが格納される。サイズ４０２には、各クラスのクラス単体のサイズ１、２、３が格納される。加重４０３には、各々のクラスＸ、Ｙ、Ｚの加重が格納される。例えばクラスＸの加重は、クラスＸから生成された全てのオブジェクトｘ１、ｘ２、ｘ３のサイズと、各々のオブジェクトｘ１、ｘ２、ｘ３の参照先のオブジェクト（ｚ１、ｚ２、ｚ３）、（ｚ１、ｚ２）、（ｚ１、ｚ２）のサイズと、を全て加算して得られる２４である。クラスＹの加重は、クラスＹから生成された全てのオブジェクトｙ１、ｙ２、ｙ３のサイズを全て加算して得られる６である。クラスＺの加重は、クラスＺから生成された全てのオブジェクトｚ１（３個）、ｚ２（３個）、ｚ３のサイズを全て加算して得られる２１である。
ここで、加重が大きいクラスほど、メモリリークの原因となるオブジェクト群の起点であると判定できる。そのため、このクラス情報テーブル１１９のケースでは、クラスＸから生成されたオブジェクトｘ１、ｘ２、ｘ３を起点オブジェクトとして検出することができる。なお、加重が予め定められた閾値（例えば２０）を超えた１又は２以上のクラス（例えばクラスＸ、Ｚ）から生成されたオブジェクトｘ１、ｘ２、ｘ３、ｚ１、ｚ２を起点オブジェクトとして検出してもよい。
図５は、複数の時点におけるＪａｖａヒープ領域１１７内のオブジェクト間の参照関係を示す図である。
図２は、所定の時点におけるＪａｖａヒープ領域１１７内のオブジェクト間の参照関係を示した。一方、この図５では、スレッド実行中の時刻ｔ１、ｔ２、ｔ３において、Ｊａｖａヒープ領域１１７の状態がそれぞれ状態５０１、５０２、５０３の順に経時変化する場合のオブジェクト間の参照関係を示している。
状態５０１では、オブジェクト５０４の参照先はオブジェクト５１０である。状態５０２では、オブジェクト５０４の参照先はオブジェクト５０５である。状態５０３では、オブジェクト５０４の参照先はオブジェクト５０６である。
プログラム実行部１１０により実行されるプログラムによっては、図５のようにオブジェクトの参照先が経時変化する場合がある。図５に示す例では、最上位の参照元であると判定できるオブジェクト５０４が、起点オブジェクトとして相応しい。オブジェクト５０４が起点オブジェクトであることを検出することができれば、生成する外部ヒープブロック１２１は一つのみで済む。
図６は、図５の時刻ｔ１におけるオブジェクト情報テーブル１１８を示す図である。このオブジェクト情報テーブル１１８は、図５の時刻ｔ１においてＪａｖａヒープ領域１１７に格納されたオブジェクトの参照先情報を管理している。
図６に示すオブジェクト情報テーブル１１８では、オブジェクトａ１（図５のオブジェクト５０４）の参照先のオブジェクトはオブジェクトｄ１（図５のオブジェクト５１０）のみである。そのため、このオブジェクト情報テーブル１１８には、図５の時刻ｔ２、ｔ３のように、オブジェクト５０４の参照先のオブジェクトがオブジェクト５０５、５０６であるケースが反映されていない。
図７は、図６のテーブルを基に生成されるクラス情報テーブル１１９を示す図である。クラスＡの加重は、クラスＡから生成されたオブジェクトａ１のサイズと、このオブジェクトａ１の参照先のオブジェクトｄ１のサイズと、を全て加算して得られる５である。クラスＢの加重は、クラスＢから生成された全てのオブジェクトｂ１、ｂ２のサイズと、各々のオブジェクトｂ１、ｂ２の参照先のオブジェクト（ｃ１、ｃ２）、（ｃ３）のサイズと、を全て加算して得られる１３である。クラスＣの加重は、クラスＣから生成された全てのオブジェクトｃ１、ｃ２、ｃ３のサイズを全て加算して得られる９である。クラスＤの加重は、クラスＤから生成されたオブジェクトｄ１のサイズの４である。
図６のテーブルを基に生成されたクラス情報テーブル１１９では、加重が最も大きいクラスはクラスＢである。そのため、クラスＢから生成されたオブジェクトｂ１、ｂ２（図５のオブジェクト５０５、５０６）を起点オブジェクトとして検出することができる。言い換えると、上記のように最上位の参照元であると判断できるオブジェクトａ１（図５のオブジェクト５０４）を起点オブジェクトとして検出できない。
このような場合に、最上位の参照元であると判断できるオブジェクト５０４を起点オブジェクトとして検出するために、本実施形態の計算機システム１では、参照先情報取得部１１２は、特定の条件を満たす度に（例えば一定時間毎に）、Ｊａｖａヒープ領域１１７に格納されたオブジェクト５０４~５１０の参照先情報を繰り返し取得する。取得された参照先情報は、オブジェクト情報テーブル１１８に出力される。
図８Ａ、図８Ｂ及び図８Ｃは、図５のケースにおけるオブジェクト情報テーブル１１８を示す図である。図８Ａ、図８Ｂ及び図８Ｃは、それぞれスレッド開始からΔｔ毎の時刻ｔ１、ｔ２、ｔ３におけるオブジェクトの参照先情報を管理している。
図８Ａに示すオブジェクト情報テーブル１１８では、図５の状態５０１におけるオブジェクトの参照先情報が管理されている。オブジェクトａ１（図５のオブジェクト５０４）の参照先のオブジェクトは、オブジェクトｄ１（図５のオブジェクト５１０）である。図８Ｂに示すオブジェクト情報テーブル１１８では、図５の状態５０２におけるオブジェクトａ１（５０４）の参照先のオブジェクトｂ１（５０５）が、オブジェクトａ１の参照先に追加されている。図８Ｃに示すオブジェクト情報テーブル１１８では、図５の状態５０３におけるオブジェクトａ１（５０４）の参照先のオブジェクトｂ２（５０５）が、オブジェクトａ１の参照先に追加されている。
以上のように、参照先情報取得部１１２は、特定の条件を満たす度に、オブジェクトの参照先情報を繰り返し取得するとともに、取得された参照先情報をオブジェクト情報テーブル１１８に追加している。このようなオブジェクト情報テーブル１１８を基に生成されたクラス情報テーブル１１９（不図示）を用いることによって、最上位の参照元であると判断できるオブジェクトａ１（図５のオブジェクト５０４）を起点オブジェクトとして検出することができる。
続いて、起点オブジェクトとして相応しくないオブジェクトが起点オブジェクトとして検出され、外部ヒープブロック１２１に移動された場合の対応処理について説明する。
図９は、複数の時点におけるＪａｖａヒープ領域１１７及び外部ヒープブロック１２１内のオブジェクト間の参照関係を示す図である。この図９では、スレッド実行中の時刻ｔ４、ｔ５、ｔ６において、Ｊａｖａヒープ領域１１７及び外部ヒープブロック１２１の状態がそれぞれ状態９０１、９０２、９０３の順に経時変化する場合のオブジェクト間の参照関係を示している。
状態９０１では、オブジェクト９０８、９０９が起点オブジェクトとして検出され、それぞれ外部ヒープブロック１２１−１、１２１−２に移動されている。状態９０２では、オブジェクト９０７はオブジェクト９０８を参照している。状態９０３では、オブジェクト９０７はオブジェクト９０９を参照している。
図９に示す例では、最上位の参照元であると判定できるオブジェクト９０７が、起点オブジェクトとして相応しい。オブジェクト９０７が起点オブジェクトであることを検出することができれば、生成する外部ヒープブロック１２１は一つのみで済む。言い換えると、オブジェクト９０８、９０９は最適な起点オブジェクトとは言えない。そのため、以下に示す図１０、図１１、特に図１１の制御ロジックにより、本実施形態の計算機システム１では、最適な起点オブジェクトとしてオブジェクト９０７を検出する。
図１０は、参照先情報取得部１１２の制御ロジックを示すフローチャートである。
まずステップ１００１では、参照先情報取得部１１２は、特定条件を満たすまで待機する（ステップ１００１）。特定条件とは、一定時間経過する又はプログラム実行部１１０がプログラム実行中にオブジェクトの参照関係が変化する等の条件である。特定条件を満たした場合（ステップ１００２でＹＥＳ）、ステップ１００３に進む。特定条件を満たさずにスレッドが終了した場合には（ステップ１００２でＮＯ）、処理を終了する。
ステップ１００３に進んだ場合、参照先情報取得部１１２は、Ｊａｖａヒープ領域１１７内に未処理のオブジェクトが存在するか否かを調査する（ステップ１００３）。未処理のオブジェクトが存在する場合には（ステップ１００４でＹＥＳ）、ステップ１００５に進み、参照先情報取得部１１２は、未処理のオブジェクトの状態を処理済みに変更し、そのオブジェクトの参照先のオブジェクトに関する情報を調査・取得する（ステップ１００５）。その後ステップ１００６では、参照先情報取得部１１２は、取得された参照先のオブジェクトに関する情報がオブジェクト情報テーブル１１８に未登録か又は登録済みかを調査する（ステップ１００６）。未登録であって登録が必要な場合には（ステップ１００７でＹＥＳ）、ステップ１００８に進み、参照先情報取得部１１２は、参照先のオブジェクトに関する情報をオブジェクト情報テーブル１１８に登録する（ステップ１００８）。その後、ステップ１００３に戻って、参照先情報取得部１１２は、次の未処理のオブジェクトが存在するか調査する。一方、登録済みであって登録が不要な場合には（ステップ１００７でＮＯ）、ステップ１００３に戻る。なお、ステップ１００４において未処理のオブジェクトが存在しない、すなわち全てのオブジェクトの処理が完了した又は処理すべきオブジェクトが存在しない場合には（ステップ１００４でＮＯ）、ステップ１００１に戻って、参照先情報取得部１１２は、再び待機状態になる。
以上に示す制御ロジックにより、参照先情報取得部１１２は、特定条件を満たす度に、Ｊａｖａヒープ領域１１７内の全ての未処理のオブジェクトの参照先情報を繰り返し取得し、オブジェクト情報テーブル１１８に登録する。
図１１は、参照元情報取得部１１６の制御ロジックを示すフローチャートである。
まずステップ１１０１では、参照元情報取得部１１６は、現在のオブジェクト情報テーブル１１８を基に各クラスの加重を算出し、クラス情報テーブル１１９に登録する（ステップ１１０１）。次にステップ１１０２では、参照元情報取得部１１６は、クラス情報テーブル１１９を参照して、加重が閾値以上のクラスが存在するか否かを判定する（ステップ１１０２）。加重が閾値以上のクラスが存在する場合には（ステップ１１０２でＹＥＳ）、ステップ１１０３に進む。一方、加重が閾値以上のクラスが存在しない場合には（ステップ１１０２でＮＯ）、処理を終了する。
ステップ１１０３に進んだ場合、参照元情報取得部１１６は、加重が閾値以上のクラスから生成されるオブジェクト、つまり起点オブジェクトを格納する外部ヒープ領域１２０（外部ヒープブロック１２１）にバリア処理を施す（ステップ１１０３）。ここでいうバリア処理とは、起点オブジェクトに対する他のオブジェクトのアクセス（図９の場合にはオブジェクト９０８、９０９に対するオブジェクト９０７からのアクセス）を検知するために施される処理である。
その後ステップ１１０４では、参照元情報取得部１１６は、バリア済み領域に対する他のオブジェクトのアクセスがあったか否かを検出する（ステップ１１０４）。他のオブジェクトのアクセスがあった場合には（ステップ１１０４でＹＥＳ）、ステップ１１０５に進んで、参照元情報取得部１１６は、アクセスしたオブジェクト、すなわち参照元のオブジェクトに関する情報を、アクセスされたオブジェクトに記録する（ステップ１１０５）。ここでは、アクセスが検知されるとＪａｖａＶＭ１０８へ検知信号が送信されるので、アクセスされたオブジェクト内に参照元のオブジェクトに関する情報を記録することができる。一方、他のオブジェクトのアクセスがない場合には（ステップ１１０４でＮＯ）、スレッド実行中は（ステップ１１０６でＮＯ）、ステップ１１０２に戻って処理を繰り返す。スレッドが終了した場合には（ステップ１１０６でＹＥＳ）、参照元情報取得部１１６は、ステップ１１０５で記録された参照元のオブジェクトに関する情報を基に、オブジェクト情報テーブル１１８を更新し（ステップ１１０８）、処理を終了する。
以上に示す制御ロジックにより、参照元情報取得部１１６は、起点オブジェクトが格納された外部ヒープ領域１２０にアクセスするオブジェクトを全て抽出し、抽出されたオブジェクトに関する情報を基に、オブジェクト情報テーブル１１８を起点オブジェクトの検出に最適なテーブルに更新することができる。
以上の処理により得られた結果に基づいて、起点となるオブジェクトを、計算機システム１が自動に若しくはユーザが手動で指定することができる。自動で指定する場合は、例えば、加重値が最も大であるクラスのオブジェクトを起点オブジェクトとして指定するようにしてもよい。手動で指定する場合は、以下に説明する表示装置１２２の画面を介して指定してもよい。
表示装置１２２に表示される画面の例について説明する。図１２は、表示装置１２２に表示される画面例を示す。画面上には、各クラス１２３に関してインスタンス数１２４、サイズ値１２５及び加重値１２６といった情報を一覧表示するとともに、起点オブジェックトの生成場所１２７を表示するようになっている。
図１２において、インスタンス数１２４、サイズ値１２５及び加重値１２６といった情報は、加重値の大きさに応じて大であるものを昇順で表示している。生成場所１２７は、クラス毎のオブジェクトを内部ヒープブロック或いは外部ヒープブロックとするかをユーザが選択可能なチェックボックスが表示される。即ち加重値が最大であるクラスＡを起点オブジェクトとして外部ヒープブロックに設ける場合、ユーザ操作により生成場所１２７の「起点（外部）」にチェックボックスを入れることで、指定を行うことができるようになっている。クラスＢ及びＣは、起点オブジェクトとしないため、「通常（内部）」にチェックボックスを入れる。）。
以上説明してきた本実施形態の計算機システム１によれば、外部ヒープ領域に移動すべき起点オブジェクトを精度良く検出し、外部ヒープ領域を効率的に利用することができる。これに伴い、ＧＣの発生頻度を抑えることもできる。また、図９の時刻ｔ４のようなケースを防ぐことによって、外部ヒープブロックの数及び生成・解放に係るコストを抑えることができる。また、表示装置１２２を介してクラス毎の加重等をユーザに提供することができ、その加重に基づいてユーザが起点オブジェクトを任意に指定することもでき、起点オブジェクトの指定に関する利便性を向上させることができる。
なお、計算機システム１のテスト環境において、最適な起点オブジェクトを検出するまでにオブジェクト情報テーブル１１８及びクラス情報テーブル１１９に格納された各種情報を、補助記憶装置１０１内のオブジェクト情報ファイル１０６及びクラス情報ファイル１０７に蓄積させておくことが好ましい。この場合には、計算機システム１の本番環境において、オブジェクト情報ファイル１０６及びクラス情報ファイル１０７を用いることによって再度オブジェクト情報テーブル１１８及びクラス情報テーブル１１９を生成することによるオーバヘッドを起こすことなく、最適な起点オブジェクトを検出することができる。
Claims (15)
- プログラムを実行するプロセッサと、メモリと、を備えた計算機システムであって、
前記メモリは、ガベージコレクタによって管理される第１の領域と、ガベージコレクタによって管理されない第２の領域と、を備え、
前記プロセッサは、
前記プログラムを実行することによって生成されたオブジェクトを、前記第１の領域に格納し、
前記第１の領域に格納されたオブジェクトの参照関係を示す情報を複数回取得し、
それら取得された前記参照関係を示す情報を組み合わせた情報に基づいて、前記第２の領域に移動すべき起点となるオブジェクトを検出し、
検出された前記起点となるオブジェクトを前記第２の領域に移動させることを特徴とする計算機システム。 - 請求項１に記載の計算機システムであって、
前記プロセッサは、所定時間が経過する度に、前記第１の領域に格納されたオブジェクトの参照関係を示す情報を取得することを特徴とする計算機システム。 - 請求項１に記載の計算機システムであって、
前記プロセッサは、前記プログラムの実行中に、前記第１の領域に格納されたオブジェクトの参照関係が変化する度に、前記第１の領域に格納されたオブジェクトの参照関係を示す情報を取得することを特徴とする計算機システム。 - 請求項１に記載の計算機システムであって、
前記プロセッサは、
前記第１の領域に格納されたオブジェクトの生成元のクラス毎に、前記クラスから生成されたオブジェクトのサイズと、該生成されたオブジェクトの参照先のオブジェクトのサイズと、の総和である加重を、取得された前記参照関係を示す情報から算出し、
算出されたクラス毎の加重に基づいて、前記起点となるオブジェクトを検出することを特徴とする記載の計算機システム。 - 請求項１に記載の計算機システムであって、
前記プロセッサは、
前記第２の領域にガード処理をし、
ガード処理がされた前記第２の領域に格納されたオブジェクトに、前記第１の領域に格納されたオブジェクトのアクセスがあった場合に、該第１の領域に格納されたオブジェクトの参照関係を示す情報に、該第２の領域に格納されたオブジェクトを追加することを特徴とする計算機システム。 - 請求項１に記載の計算機システムであって、
前記計算機システムは、データを格納するための補助記憶装置をさらに備え、
前記補助記憶装置には、当該計算機システムのテスト環境において検出された前記起点となるオブジェクトを求めるための情報が、本番環境用に格納されることを特徴とする計算機システム。 - 請求項１に記載の計算機システムであって、
前記計算機システムは、表示装置をさらに備え、
前記プロセッサは、
前記組み合わせた情報を表示装置に表示することを特徴とする計算機システム。 - プログラムを実行するプロセッサと、メモリと、を備えた計算機システムにおけるメモリ管理方法であって、
前記メモリは、ガベージコレクタによって管理される第１の領域と、ガベージコレクタによって管理されない第２の領域と、を備えており、
前記方法は、
前記プロセッサが、前記プログラムを実行することによって生成されたオブジェクトを、前記第１の領域に格納する手順と、
前記プロセッサが、前記第１の領域に格納されたオブジェクトの参照関係を示す情報を複数回取得する手順と、
前記プロセッサが、それら取得された前記参照関係を示す情報を組み合わせた情報に基づいて、前記第２の領域に移動すべき起点となるオブジェクトを検出する手順と、
前記プロセッサが、検出された前記起点となるオブジェクトを前記第２の領域に移動させる手順と、
を含むことを特徴とするメモリ管理方法。 - 請求項８に記載のメモリ管理方法であって、
前記プロセッサは、所定時間が経過する度に、前記第１の領域に格納されたオブジェクトの参照関係を示す情報を取得することを特徴とするメモリ管理方法。 - 請求項８に記載のメモリ管理方法であって、
前記プロセッサは、前記プログラムの実行中に、前記第１の領域に格納されたオブジェクトの参照関係が変化する度に、前記第１の領域に格納されたオブジェクトの参照関係を示す情報を取得することを特徴とするメモリ管理方法。 - 請求項８に記載のメモリ管理方法であって、
前記起点となるオブジェクトを検出する手順において、
前記プロセッサは、前記第１の領域に格納されたオブジェクトの生成元のクラス毎に、前記クラスから生成されたオブジェクトのサイズと、該生成されたオブジェクトの参照先のオブジェクトのサイズと、の総和である加重を、取得された前記参照関係を示す情報から算出し、
算出されたクラス毎の加重に基づいて、前記起点となるオブジェクトを検出することを特徴とするメモリ管理方法。 - 請求項８に記載のメモリ管理方法であって、
前記方法は、さらに、
前記プロセッサが、前記第２の領域にガード処理をする手順と、
ガード処理がされた第２の領域に格納されたオブジェクトに、前記第１の領域に格納されたオブジェクトのアクセスがあった場合に、前記プロセッサが、該第１の領域に格納されたオブジェクトの参照関係を示す情報に、該第２の領域に格納されたオブジェクトを追加する手順と、
を含むことを特徴とするメモリ管理方法。 - 請求項８に記載のメモリ管理方法であって、
前記計算機システムは、データを格納するための補助記憶装置をさらに備え、
前記方法は、
前記プロセッサが、当該計算機システムのテスト環境において検出された前記起点となるオブジェクトを求めるための情報を、本番環境用に前記補助記憶装置に格納する手順を含むことを特徴とするメモリ管理方法。 - 請求項８に記載のメモリ管理方法であって、
前記計算機システムは、表示装置をさらに備え、
前記方法は、
前記組み合わせた情報を前記表示装置に表示する手順を更に含むことを特徴とするメモリ管理方法。 - プログラムを実行するプロセッサと、メモリと、を備えた計算機システムに用いられるメモリ管理プログラムであって、
前記メモリは、ガベージコレクタによって管理される第１の領域と、ガベージコレクタによって管理されない第２の領域と、を備えており、
前記メモリ管理プログラムは、
前記プログラムを実行することによって生成されたオブジェクトを、前記第１の領域に格納する手順と、
前記第１の領域に格納されたオブジェクトの参照関係を示す情報を複数回取得する手順と、
それら取得された前記参照関係を組み合わせた情報に基づいて、前記第２の領域に移動すべき起点となるオブジェクトを検出する手順と、
検出された前記起点となるオブジェクトを前記第２の領域に移動させる手順と、
を前記計算機システムに実行させることを特徴とするメモリ管理プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2010/053477 WO2011104889A1 (ja) | 2010-02-25 | 2010-02-25 | 計算機システム、メモリ管理方法及びメモリ管理プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2010/053477 WO2011104889A1 (ja) | 2010-02-25 | 2010-02-25 | 計算機システム、メモリ管理方法及びメモリ管理プログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2011104889A1 true WO2011104889A1 (ja) | 2011-09-01 |
Family
ID=44506331
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/JP2010/053477 WO2011104889A1 (ja) | 2010-02-25 | 2010-02-25 | 計算機システム、メモリ管理方法及びメモリ管理プログラム |
Country Status (1)
| Country | Link |
|---|---|
| WO (1) | WO2011104889A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013128492A1 (ja) * | 2012-03-02 | 2013-09-06 | 株式会社日立製作所 | 計算機、プログラム及びメモリ管理方法 |
| JP2013205911A (ja) * | 2012-03-27 | 2013-10-07 | Nec Corp | データ参照元特定システム及びその特定方法、並びにそのコンピュータ・プログラム |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003186737A (ja) * | 2001-12-14 | 2003-07-04 | Matsushita Electric Ind Co Ltd | ガベージコレクション装置、ガベージコレクション方法及びガベージコレクションプログラム |
-
2010
- 2010-02-25 WO PCT/JP2010/053477 patent/WO2011104889A1/ja active Application Filing
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003186737A (ja) * | 2001-12-14 | 2003-07-04 | Matsushita Electric Ind Co Ltd | ガベージコレクション装置、ガベージコレクション方法及びガベージコレクションプログラム |
Non-Patent Citations (1)
| Title |
|---|
| MOTOKI KOHATA ET AL.: "Java ni Okeru Meijiteki Memory Kanri", TRANSACTIONS OF INFORMATION PROCESSING SOCIETY OF JAPAN RONBUNSHI JOURNAL, vol. 50, no. 7, 15 July 2009 (2009-07-15), pages 1693 - 1715 * |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2013128492A1 (ja) * | 2012-03-02 | 2013-09-06 | 株式会社日立製作所 | 計算機、プログラム及びメモリ管理方法 |
| JP5657169B2 (ja) * | 2012-03-02 | 2015-01-21 | 株式会社日立製作所 | 計算機、プログラム及びメモリ管理方法 |
| JP2013205911A (ja) * | 2012-03-27 | 2013-10-07 | Nec Corp | データ参照元特定システム及びその特定方法、並びにそのコンピュータ・プログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5723208B2 (ja) | コールバックを用いたソフトウェアの動的計測のためのフェイルセーフメカニズム | |
| US9582418B2 (en) | Confirming the sensitivity of a data object in a managed object heap | |
| US9424082B2 (en) | Application startup page fault management in a hardware multithreading environment | |
| US8443178B2 (en) | Operating system image shrinking apparatus and method and computer readable tangible medium storing a program for operating system image shrinking | |
| JP2012084150A (ja) | ２パス自動アプリケーション計測 | |
| US8438557B2 (en) | Reusing an application object | |
| JP6179331B2 (ja) | ログ出力条件設定プログラム、装置、および方法 | |
| US10768928B2 (en) | Software development work item management system | |
| US8799716B2 (en) | Heap dump occurrence detection | |
| US20180137002A1 (en) | Thread based dynamic data collection | |
| JP5281452B2 (ja) | メモリ管理方法、コンピュータ、及び、メモリ管理プログラム | |
| JP2011053862A (ja) | メモリ管理方法、計算機システム及びプログラム | |
| WO2011104889A1 (ja) | 計算機システム、メモリ管理方法及びメモリ管理プログラム | |
| US9165007B2 (en) | Log message optimization to ignore or identify redundant log messages | |
| US10031840B2 (en) | Method of ascertaining primary cause of memory consumption in program, and computer system and computer program for the same | |
| US20180173728A1 (en) | Information processing apparatus and method | |
| US8806448B2 (en) | Dynamic instrumentation method and apparatus for tracing and analyzing a program | |
| US9128851B2 (en) | Prefetching for multiple parent cores in a multi-core chip | |
| JP5728979B2 (ja) | 情報処理装置、ソフトウェア検査方法およびソフトウェア検査プログラム | |
| EP2960798B1 (en) | Automatic memory leak detection | |
| JP4959781B2 (ja) | オブジェクト生成地点記録方法およびプログラム | |
| JP5199975B2 (ja) | メモリ管理方法、メモリ管理プログラム、及び、情報処理装置 | |
| JP2013105349A (ja) | 動的リンクライブラリの更新、実行方法 | |
| JP6010961B2 (ja) | データ参照元特定システム及びその特定方法、並びにそのコンピュータ・プログラム | |
| JP2009199391A (ja) | ガーベージコレクション方法及びその実施装置と処理プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 10846552 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 10846552 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: JP |