JP5867633B1 - 情報処理装置、制御方法及びプログラム - Google Patents

Abstract

【課題】アプリケーションの実行時に実際に使用されているヒープ領域サイズを精度良く算出すること。【解決手段】本発明にかかる情報処理装置は、アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する登録手段と、所定の契機により、所定のアプリケーションの識別情報に対応付けられたオブジェクト特定情報のリストをロードオブジェクト管理情報から取得する第１の取得手段と、リストに含まれる各オブジェクト特定情報により特定される各オブジェクトをヒープ領域から取得する第２の取得手段と、取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する第３の取得手段と、取得された全てのオブジェクトのメモリ使用量の合計値を算出する算出手段と、を備える。【選択図】図１

Description

本発明は、情報処理装置、制御方法及びプログラムに関し、特に、アプリケーションのメモリ使用量を算出するための情報処理装置、制御方法及びプログラムに関する。

Java（登録商標）プログラムを実行するＪＶＭ（Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）は、Javaプログラムが使用するヒープメモリ領域のサイズを、起動時に指定することができる。ヒープメモリ領域のサイズは適切な量を設定することが望ましい。ヒープメモリ領域が少な過ぎる場合には、Javaプログラム実行時にメモリが枯渇してガベージコレクションが頻発し、アプリケーションのパフォーマンスが低下してしまう。また、ヒープメモリ領域が多過ぎる場合には、ガベージコレクション実行時にガベージコレクションの処理対象となるオブジェクトが多くなるためにJavaアプリケーションが長時間停止するためである。このことはWebアプリケーションを実行するアプリケーションサーバでも同様である。

ところで、アプリケーションサーバは、１つのＪＶＭ上でアプリケーションサーバ自身とアプリケーションサーバに配備した０個以上のアプリケーションが動作する。このため、アプリケーションサーバが動作するJavaプロセスの適切なヒープメモリサイズを算出するためには、各配備アプリケーションが使用するヒープメモリサイズを知る必要がある。

また、アプリケーションサーバに複数個アプリケーションを配備する環境において、配備アプリケーションがメモリリークを起こした場合、複数のアプリケーションがメモリ空間を共有するため、どのアプリケーションがメモリリークを起こしているのかを特定するのが困難である。

ここで、特許文献１には、メモリ不足エラーやＪａｖａアプリケーションの追加または削除など、ヒープ領域のサイズの変更要因を検出した場合に、ヒープ領域のサイズを変更する技術が開示されている。

特開２０１１−０４８５９０号公報

しかしながら、特許文献１にかかる技術は、アプリケーション単位のヒープ領域サイズの精度が不十分であるという問題点がある。その理由は、特許文献１にかかる技術では、アプリケーション単位のヒープ領域サイズが、アプリケーション定義ファイルとして予め定義された値であるため、当該アプリケーションの実行時に実際に使用されているヒープ領域を測定したものではないためである。

本発明は、このような問題点を解決するためになされたものであり、アプリケーションの実行時に実際に使用されているヒープ領域サイズを精度良く算出するための情報処理装置、制御方法及びプログラムを提供することを目的とする。

本発明の第１の態様にかかる情報処理装置は、
アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する登録手段と、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得する第１の取得手段と、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得する第２の取得手段と、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する第３の取得手段と、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する算出手段と、
を備える。

本発明の第２の態様にかかる情報処理装置の制御方法は、
アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録し、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得し、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得し、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得し、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する。

本発明の第３の態様にかかるプログラムは、
アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する処理と、
所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得する処理と、
前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得する処理と、
前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する処理と、
前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する処理と、
をコンピュータに実行させる。

本発明により、アプリケーションの実行時に実際に使用されているヒープ領域サイズを精度良く算出するための情報処理装置、制御方法及びプログラムを提供することができる。

本発明の実施の形態１にかかる情報処理装置の構成を示すブロック図である。 本発明の実施の形態１にかかるメモリ使用量算出処理の流れを示すフローチャートである。 本発明の実施の形態２にかかる情報処理装置のハードウェア構成を示すブロック図である。 本発明の実施の形態２にかかるＪＶＭ、アプリケーションサーバ、配備アプリケーションの関係を説明するための概要図である。 本発明の実施の形態２にかかるアプリケーションサーバの起動時の処理の流れを説明するためのフローチャートである。 本発明の実施の形態２にかかるオブジェクト生成時の処理の流れを説明するためのフローチャートである。 本発明の実施の形態２にかかるアプリケーション配備時の処理の流れを説明するためのフローチャートである。 本発明の実施の形態２にかかるアプリケーション配備解除時の処理の流れを説明するためのフローチャートである。 本発明の実施の形態２にかかる配備アプリケーションのヒープメモリ使用量を測定する処理の流れを説明するためのフローチャートである。 本発明の実施の形態２にかかるルートオブジェクト参照表の例を示す図である。 本発明の実施の形態２にかかる配備アプリケーションが使用するオブジェクトの例を示す図である。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。

（実施形態１）
図１は、本発明の実施の形態１にかかる情報処理装置１の構成を示すブロック図である。情報処理装置１は、ヒープ領域１０と、ロードオブジェクト管理情報２０と、登録手段３０と、第１の取得手段４０と、第２の取得手段５０と、第３の取得手段６０と、算出手段７０とを備える。

ヒープ領域１０は、情報処理装置１が有する記憶装置（不図示）内のメモリ領域のうち、アプリケーションを実行するために割り当てられる領域（ヒープメモリ）である。ロードオブジェクト管理情報２０は、ヒープ領域１０にロードされたオブジェクト１１を管理するための情報である。ロードオブジェクト管理情報２０は、アプリケーション識別情報２１と、オブジェクト特定情報２２とを対応付けて保持する。オブジェクト特定情報２２は、オブジェクト１１を特定する情報である。オブジェクト特定情報２２は、オブジェクト１１のロードデータ自体ではなく、オブジェクト１１を参照するための情報である。例えば、オブジェクト特定情報２２は、弱参照オブジェクトであることが望ましいが、これに限定されない。尚、ロードオブジェクト管理情報２０は、ヒープ領域１０と同一又は異なる記憶装置内に存在するものである。

登録手段３０は、アプリケーションの実行に応じてヒープ領域１０にオブジェクト１１が生成された際に、オブジェクト１１を特定するオブジェクト特定情報２２を、当該アプリケーションのアプリケーション識別情報２１と対応付けてロードオブジェクト管理情報に登録する。第１の取得手段４０は、所定の契機により、所定のアプリケーション識別情報２１に対応付けられたオブジェクト特定情報２２のリストをロードオブジェクト管理情報２０から取得する。第２の取得手段５０は、前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトをヒープ領域１０から取得する。第３の取得手段６０は、取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する。すなわち、ここでは、所定のアプリケーション自体に直接実装されていないオブジェクトであっても、参照先のオブジェクトの全てが取得される。算出手段７０は、取得された全てのオブジェクトのメモリ使用量の合計値を算出する。

図２は、本発明の実施の形態１にかかるメモリ使用量算出処理の流れを示すフローチャートである。まず、登録手段３０は、アプリケーションの実行に応じてヒープ領域１０にオブジェクト１１が生成された際に、オブジェクト１１を特定するオブジェクト特定情報２２を、当該アプリケーションの識別情報２１と対応付けてロードオブジェクト管理情報２０に登録する（Ｓ１１）。

次に、第１の取得手段４０は、所定の契機により、所定のアプリケーションの識別情報２１に対応付けられたオブジェクト特定情報２２のリストをロードオブジェクト管理情報２０から取得する（Ｓ１２）。続いて、第２の取得手段５０は、前記リストに含まれる各オブジェクト特定情報２２により特定される各オブジェクトをヒープ領域１０から取得する（Ｓ１３）。そして、第３の取得手段６０は、取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する（Ｓ１４）。その後、算出手段７０は、取得された全てのオブジェクトのメモリ使用量の合計値を算出する（Ｓ１５）。

このように、本発明の実施の形態では、当該アプリケーション内に実装された各クラスのうち、ヒープ領域に実際に生成されたオブジェクトについて、当該オブジェクトを特定する情報を保持しておくものである。そして、メモリ使用量の算出時（所定の契機）においても実際にヒープ領域に存在するオブジェクトを対象とすることができる。そして、当該オブジェクトから参照されるオブジェクトを全て取得することで、当該アプリケーションの動作のために実際に必要とされるオブジェクトを網羅するものである。そして、網羅された各オブジェクトの使用メモリサイズを元に、実際に確保されているヒープ領域を正確に算出することができる。

（実施形態２）
本実施の形態２は、上述した実施の形態１の具体例である。ここで、本実施の形態が解決しようとする課題を詳述する。

例えば、Ｊａｖａ ＥＥアプリケーションサーバではＷｅｂアプリケーションやＥＪＢアプリケーションを複数個配備することができる。このとき、アプリケーションサーバとアプリケーションサーバに配備したアプリケーションは、１つのＪａｖａ ＶＭプロセス上で動作し、アプリケーションサーバと配備アプリケーションは、Ｊａｖａ ＶＭのヒープメモリ空間を共有する。このため、ある配備アプリケーションがメモリリーク等を原因にヒープメモリを大量に確保してヒープメモリが枯渇すると、その影響を他の配備アプリケーションやアプリケーションサーバも受ける。

尚、Javaにおける実行時のヒープメモリ使用量はhprofに代表されるメモリダンプツールを用いることで測定が可能である。しかしながら、当該メモリダンプツールは、javaプロセス全体のヒープメモリ使用量であり、アプリケーションサーバ上で動作する各配備アプリケーションのヒープメモリ使用量を知ることは出来ない。また、メモリリークが疑われないアプリケーションサーバ自身のヒープメモリの情報も取得するため、メモリの取得にかかる時間が長くなるという問題がある。

そこで、本実施の形態では以下の構成により上述した課題を解決するものである。

図３は、本発明の実施の形態２にかかる情報処理装置２００のハードウェア構成を示すブロック図である。情報処理装置２００は、メモリ３００、ＣＰＵ４００及びハードディスク５００を備えるコンピュータ装置である。尚、情報処理装置２００は、汎用的なコンピュータ装置が備える他の構成を有しており、以下では図示及び説明を省略する。

メモリ３００は、揮発性記憶装置である。メモリ３００は、ヒープメモリ３１０、ルートオブジェクト参照表３２０及びオブジェクト一時記憶部３３０を含む。ヒープメモリ３１０は、上述したヒープ領域１０の一例である。ヒープ領域１０は、ＪＶＭ５２０上で動作するプログラムが生成するオブジェクト３１１、３１２を記憶するメモリ領域である。ルートオブジェクト参照表３２０は、上述したロードオブジェクト管理情報２０の一例である。ルートオブジェクト参照表３２０は、キーをクラスローダ情報３２１、値を弱参照オブジェクト３２２とするマップのデータ構造である。クラスローダ情報３２１は、複数のアプリケーション５４０のそれぞれを識別するアプリケーション識別情報２１の一例である。弱参照オブジェクト３２２は、上述したオブジェクト特定情報２２の一例である。ここで、弱参照とは、参照先のオブジェクトをガベージコレクタ５２２による解放から守ることのできない参照である。

オブジェクト一時記憶部３３０は、算出対象オブジェクト３３１を記憶する記憶領域である。算出対象オブジェクト３３１は、参照オブジェクト取得部５２３によりオブジェクト一時記憶部３３０に格納される。また、オブジェクト一時記憶部３３０は、メモリ使用量計算部５２４がメモリ使用量を計算する際に用いられる。そのため、オブジェクト一時記憶部３３０は、参照オブジェクト取得部５２３及びメモリ使用量計算部５２４からアクセスされる。

尚、メモリ３００には、上記の他にＯＳ５１０やＪＶＭ５２０の実行領域が通常通り確保されるものとする。

ハードディスク５００は、ＯＳ（Operating System）５１０、ＪＶＭ５２０、アプリケーションサーバ５３０、アプリケーション５４０を記憶する不揮発性記憶装置である。ＯＳ５１０は、公知のものと同様であるため説明を省略する。ＪＶＭ５２０は、Javaプログラムを実行するアプリケーション実行装置の一例である。特に、本実施の形態にかかるＪＶＭ５２０は、オブジェクト生成部５２１、ガベージコレクタ５２２、参照オブジェクト取得部５２３及びメモリ使用量計算部５２４を備える。尚、ＪＶＭ５２０は、これらの構成の他、図示しない一般的な構成を含むものとする。

オブジェクト生成部５２１は、ＪＶＭ５２０上でのオブジェクトの生成処理を行う。ガベージコレクタ５２２は、ヒープメモリ３１０に存在するオブジェクトの使用状況を確認し、使用されなくなったオブジェクトをヒープメモリ３１０から解放し、そのメモリ領域を他のオブジェクトに割り当て可能にする。

参照オブジェクト取得部５２３は、任意のオブジェクトから参照されるオブジェクトを再帰的に取得し、オブジェクト一時記憶部３３０に算出対象オブジェクト３３１として格納する。メモリ使用量計算部５２４は、アプリケーションサーバ５３０に配備された任意のアプリケーション５４０のヒープメモリ使用量を計算する。

アプリケーションサーバ５３０は、複数のアプリケーション５４０の実行を管理するサーバソフトウェアである。アプリケーションサーバ５３０は、配備部５３１を備える。配備部５３１は、アプリケーションサーバ５３０の管理者によるアプリケーション配備要求を受け付けて、要求されたアプリケーション５４０をアプリケーションサーバ５３０に配備し、アプリケーション５４０を実行可能な状態にする。また、配備部５３１は、アプリケーションサーバ５３０の管理者によるアプリケーション配備解除要求を受け付けて、要求されたアプリケーション５４０を停止し、アプリケーションサーバ５３０から削除する。

アプリケーション５４０は、１以上のＪａｖａのクラス５４２が実装されたＪａｖａアプリケーションである。また、アプリケーション５４０は、配備部５３１に生成されたクラスローダ５４１を含むということができる。

情報処理装置２００は、ＣＰＵ４００が、ハードディスク５００からＯＳ５１０、ＪＶＭ５２０、アプリケーションサーバ５３０及びアプリケーション５４０を読み出し、メモリ３００上に展開して実行することで、本発明の実施の形態を実現する。

図４は、本発明の実施の形態２にかかるＪＶＭ、アプリケーションサーバ、配備アプリケーションの関係を説明するための概要図である。上述した図３は、本実施の形態のハードウェア構成を図示したものであり、図４は図３で示した各構成について、制御の関係を中心に示した概念図といえる。

ＪＶＭ１００は、本実施の形態の一実現例である。ＪＶＭ１００は、図３のＯＳ５１０及びＪＶＭ５２０がＣＰＵ４００により情報処理装置２００上で実行された状態を示す。ＪＶＭ１００は、オブジェクト生成部１０４、ガベージコレクタ１０６、参照オブジェクト取得部１０３及びメモリ使用量計算部１０１として動作し、オブジェクト一時記憶部１０２、ヒープメモリ１０５及びアプリケーションサーバ１１０を制御する。尚、これらの構成は、それぞれ図３のオブジェクト生成部５２１、ガベージコレクタ５２２、参照オブジェクト取得部５２３、メモリ使用量計算部５２４、ヒープメモリ３１０、オブジェクト一時記憶部３３０及びアプリケーションサーバ５３０に対応する。

また、アプリケーションサーバ１１０は、配備部１１１、ルートオブジェクト参照表１１２、アプリケーション１２０ａ〜１２０ｃを制御する。尚、これらの構成は、それぞれ図３の配備部５３１、ルートオブジェクト参照表３２０、アプリケーション５４０に対応する。

アプリケーションサーバ１１０は、起動時に配備済みのアプリケーションのアプリケーションクラスローダを取得し、ルートオブジェクト参照表１１２にアプリケーションクラスローダ１１３として登録する。アプリケーションサーバ１１０は、１以上のアプリケーションが動作する。

配備部１１１は、アプリケーションサーバ１１０の起動後に、未配備のアプリケーション１２０ａ〜１２０ｃをアプリケーションサーバ１１０に配備する際に、アプリケーションごとにユニークなアプリケーションクラスローダ１２１ａ〜１２１ｃを生成する。その後、配備部１１１は、ルートオブジェクト参照表１１２に新規エントリーを作成し、生成したアプリケーションクラスローダをルートオブジェクト参照表１１２のアプリケーションクラスローダ１１３として登録する。

ここで、一般に、アプリケーションサーバ１１０は、配備する異なるアプリケーションでの同じ名前のクラスが競合することを避けるため、アプリケーションごとに異なるクラスローダを用いてアプリケーションのクラスをロードしている。

また、配備部１１１は、配備解除を要求されたアプリケーション（例えば、アプリケーション１２０ａ）を停止し、アプリケーションサーバ１１０上から停止したアプリケーション１２０ａを削除する。この時、配備部１１１は、アプリケーション１２０ａのアプリケーションクラスローダ１２１ａをアプリケーションクラスローダ１１３に持つエントリーをルートオブジェクト参照表１１２から削除する。

アプリケーション１２０ａ〜１２０ｃは、アプリケーションサーバ１１０に配備されたアプリケーションである。アプリケーション１２０ａ〜１２０ｃは、自己に定義されたクラスを、配備部１１１が生成したアプリケーションクラスローダ１２１ａ〜１２１ｃによりオブジェクトを生成させる。つまり、アプリケーションクラスローダ１２１ａ〜１２１ｃは、ヒープメモリ１０５に対してクラスのロードを実行する。アプリケーションクラスローダ１２１ａ〜１２１ｃは、ロードの実行時に、オブジェクト生成部１０４を呼び出す。

オブジェクト生成部１０４は、アプリケーションサーバ１１０やアプリケーション１２０ａ〜１２０ｃに実装されたクラスからオブジェクトを生成する際にクラスローダから呼び出され、生成したオブジェクトをヒープメモリ１０５に格納する。併せて、本実施の形態にかかるオブジェクト生成部１０４は、上述した登録手段３０としても機能する。具体的には、オブジェクト生成部１０４は、生成したオブジェクトの実装クラスのクラスローダを調べる。そして、当該クラスローダがアプリケーションサーバ１１０上のアプリケーション１２０ａ〜１２０ｃのものである場合、オブジェクト生成部１０４は、生成したオブジェクトへの弱参照オブジェクトを作成し、ルートオブジェクト参照表１１２内の該当するアプリケーションクラスローダ１１３に対応付けて弱参照リスト１１４に弱参照オブジェクトを格納する。

ガベージコレクタ１０６は、例えば、ヒープメモリ１０５上のオブジェクトＡが他のどのオブジェクトからも参照されていない場合に、オブジェクトＡが使用されなくなったと判断する。また、ガベージコレクタ１０６は、オブジェクトＡへの全ての参照の強さが弱参照以下である場合も、オブジェクトＡを使用されなくなったと判断する。

オブジェクト一時記憶部１０２は、ヒープメモリ１０５内のオブジェクトのうち、メモリ使用量の算出対象であるアプリケーションの実行に応じて生成されたオブジェクトの情報を展開する領域である。このため、ヒープメモリ１０５の確保サイズを大きく設定してヒープメモリ１０５内にオブジェクトが大量に確保されれば、オブジェクト一時記憶部１０２が使用するデータサイズも大きくなる。これにより、オブジェクト一時記憶部１０２がシステムやＪＶＭ１００の動作に悪影響を与えることを防ぐために、オブジェクト一時記憶部１０２は図４のようにＪＶＭ１００内に確保せずに、例えば他のプロセス内部や補助記憶領域などのＪＶＭ１００の外部に確保してもよい。

メモリ使用量計算部１０１は、オブジェクト一時記憶部１０２に格納されたオブジェクトのサイズの総和をメモリ使用量の合計値とする。または、メモリ使用量計算部１０１は、複数のアプリケーションの間でオブジェクトが重複する場合、当該重複分のメモリ使用量を総和から削除する。

図５は、本発明の実施の形態２にかかるアプリケーションサーバの起動時の処理の流れを説明するためのフローチャートである。まず、アプリケーションサーバ１１０は、管理者等の要求に応じて、ＪＶＭ１００上で起動する（Ｓ２１）。次に、アプリケーションサーバ１１０は、配備済みのアプリケーション（例えば、アプリケーション１２０ａ）を起動し、アプリケーション１２０ａのアプリケーションクラスローダ１２１ａをルートオブジェクト参照表１１２に追加する（Ｓ２２）。

これにより、ルートオブジェクト参照表１１２内に、配備アプリケーションのオブジェクト生成時における当該オブジェクトへの弱参照オブジェクトの登録先となるエントリーが生成される。この処理は、アプリケーションサーバ１１０に配備されたアプリケーションのうち、ヒープメモリの測定対象となり得る全てアプリケーションに対して行う。

図６は、本発明の実施の形態２にかかるオブジェクト生成時の処理の流れを説明するためのフローチャートである。まず、アプリケーションサーバ１１０又はアプリケーション１２０ａ〜１２０ｃの実行中に、定義されたクラスのオブジェクトの生成が必要になった際に、アプリケーションクラスローダからオブジェクト生成部１０４が呼び出される。そして、オブジェクト生成部１０４は、該当のクラスからオブジェクトを生成する（Ｓ３１）。

次に、オブジェクト生成部１０４は、生成したオブジェクトのクラスローダを取得する（Ｓ３２）。そして、オブジェクト生成部１０４は、取得したクラスローダがルートオブジェクト参照表１１２のアプリケーションクラスローダ１１３に存在するか否かを判定する（Ｓ３３）。ここで、ルートオブジェクト参照表１１２のアプリケーションクラスローダ１１３には、ヒープメモリの取得対象となり得る全ての配備アプリケーション１２０ａ〜１２０ｃのアプリケーションクラスローダ１２１ａ〜１２１ｃが登録されている。また、配備アプリケーション１２０ａ〜１２０ｃ以外のクラスローダは、アプリケーションクラスローダ１１３に存在しない。そのため、この判定により、生成されたオブジェクトがアプリケーション１２０ａ〜１２０ｃで定義されたクラスであるか否かが判別できる。

ステップＳ３３においてクラスローダが存在すると判定した場合、オブジェクト生成部１０４は、生成するオブジェクトの弱参照オブジェクトを生成する。そして、オブジェクト生成部１０４は、生成した弱参照オブジェクトを、該当するアプリケーションクラスローダ１１３に対応する弱参照リスト１１４に追加する（Ｓ３４）。これにより、後述するヒープメモリの測定時にアプリケーションごとに生成されたオブジェクトを弱参照リスト１１４から取得することができるようになる。一方、ステップＳ３３においてクラスローダが存在しないと判定した場合、当該処理を終了する。

図７は、本発明の実施の形態２にかかるアプリケーション配備時の処理の流れを説明するためのフローチャートである。まず、アプリケーションサーバ１１０は、運用者（管理者）からアプリケーションの配備要求を受け付ける（Ｓ４１）。ここで、配備要求には、配備対象のアプリケーションが指定されているものとする。

次に、配備部１１１は、指定されたアプリケーション（例えば、アプリケーション１２０ａ）に対応するアプリケーションクラスローダ１２１ａを生成し、ルートオブジェクト参照表１１２のアプリケーションクラスローダ１１３に追加する（Ｓ４２）。生成されるアプリケーションクラスローダ１２１ａは、配備するアプリケーション１２０ａに定義されたクラスを読み込むものである。

続いて、配備部１１１は、生成したアプリケーションクラスローダ１２１ａを用いて配備アプリケーションをロードし、アプリケーション１２０ａをアプリケーションサーバ１１０に配備する（Ｓ４３）。

図８は、本発明の実施の形態２にかかるアプリケーション配備解除時の処理の流れを説明するためのフローチャートである。まず、アプリケーションサーバ１１０は、運用者（管理者）からアプリケーションの配備解除要求を受け付ける（Ｓ４１）。ここで、配備解除要求には、配備解除対象のアプリケーションが指定されているものとする。

次に、配備部１１１は、配備解除を要求されたアプリケーション（例えば、アプリケーション１２０ａ）をアプリケーションサーバ１１０から配備解除する（Ｓ５２）。そして、配備部１１１は、配備解除を要求されたアプリケーション１２０ａのアプリケーションクラスローダ１２１ａをアプリケーションクラスローダ１１３から削除する（Ｓ５３）。すなわち、配備部１１１は、ステップＳ５２で配備解除したアプリケーション１２０ａのアプリケーションクラスローダ１２１ａに対応するエントリーを、ルートオブジェクト参照表１１２から削除する。これにより、ルートオブジェクト参照表１１２とアプリケーション１２０ａとにおいてクラスローダの整合性を取ることができる。

図９は、本発明の実施の形態２にかかる配備アプリケーションのヒープメモリ使用量を測定する処理の流れを説明するためのフローチャートである。ここで、当該ヒープメモリ使用量の測定処理は、運用者の要求、定期的なスケジュール、ＪＶＭのフルガーベージコレクションの発生などを契機に実行することが挙げられる。

まず、アプリケーションサーバ１１０は、ヒープメモリ使用量の測定対象であるアプリケーションのクラスローダを取得する（Ｓ６１）。次に、アプリケーションサーバ１１０は、取得したクラスローダに対応する弱参照インスタンスの一覧をルートオブジェクト参照表１１２から取得する（Ｓ６２）。

ここで、ルートオブジェクト参照表１１２は、上述した通り、アプリケーションクラスローダ１１３をキーに、弱参照リスト１１４を値に持つマップである。そして、キーと値は１対多の関係を持つ。そして、上述した図５〜図７の処理により弱参照リスト１１４は登録済みであり、一部は図８により削除済みである。このため、アプリケーションサーバ１１０は、クラスローダに対応する弱参照インスタンスの一覧をルートオブジェクト参照表１１２から取得することで、ヒープメモリ１０５内に存在する、対象アプリケーションで定義されたクラスのオブジェクトへの弱参照の一覧が取得できる。

図１０は、本発明の実施の形態２にかかるルートオブジェクト参照表の例を示す図である。例えば、アプリケーション１２０ａがヒープメモリ使用量の測定対象である場合、アプリケーションサーバ１１０は、ルートオブジェクト参照表１１２を参照し、アプリケーションクラスローダ１２１ａに対応付けられている弱参照リスト１１４である、オブジェクト１２２ａ１、１２２ａ２、・・・のそれぞれへの弱参照オブジェクトを取得する。

図９に戻り説明を続ける。ここで、アプリケーションサーバ１１０は、弱参照インスタンスの一覧の各要素について、ステップＳ６４からＳ６８を繰返す（Ｓ６３）。まず、アプリケーションサーバ１１０は、弱参照インスタンスが参照するオブジェクトをヒープメモリ１０５から取得する（Ｓ６４）。

そして、アプリケーションサーバ１１０は、弱参照インスタンスが参照するオブジェクトの取得に成功したか否かを判定する（Ｓ６５）。ここで上述した通り、弱参照とは、参照先のオブジェクトをガベージコレクタ１０６による解放から守ることのできない参照である。そのため、弱参照のみで参照されるオブジェクトは、ガベージコレクタ１０６によりいつでも解放することができる。従って、参照先のオブジェクトがどこからも参照されなくなった場合は、ガベージコレクタ１０６により解放されている可能性があり、ステップＳ６５においてオブジェクトの取得に失敗する。

ステップＳ６５において失敗と判定した場合、アプリケーションサーバ１１０は、ルートオブジェクト参照表１１２の弱参照リスト１１４から、この弱参照インスタンスを削除する（Ｓ６６）。尚、この処理は、ステップＳ６６のタイミングで実施する代わりに、ガベージコレクションが完了するごとに実施してもよい。その場合、デメリットとしてガベージコレクションを実施するたびに全ての弱参照オブジェクトの参照状況を確認する処理コストが発生する。しかしながら、参照を持たない弱参照オブジェクトが長期間ヒープメモリ領域にとどまり続けることを防ぐ事ができる。

ステップＳ６５において成功と判定した場合、アプリケーションサーバ１１０は、取得したオブジェクトをオブジェクト一時記憶部１０２に格納する（Ｓ６７）。尚、既にオブジェクト一時記録領域１０２に該当のオブジェクトが存在する場合には、アプリケーションサーバ１１０は格納を行わなくても良い。

続いて、参照オブジェクト取得部１０３は、オブジェクト一時記憶部１０２に格納されたオブジェクトから参照されるオブジェクトを全て再帰的に取得し、オブジェクト一時記憶領域１０２に格納する（Ｓ６８）。このとき、オブジェクト一時記憶領域１０２に同じメモリアドレスにあるオブジェクトを複数登録することを避けるため、既にオブジェクト一時記憶領域１０２に該当のオブジェクトが記録されている場合、参照オブジェクト取得部１０３は記録をしない。また、参照オブジェクト取得部１０３は、そのオブジェクトが参照するオブジェクトについての参照オブジェクトの探索は行わない。そして、アプリケーションサーバ１１０及び参照オブジェクト取得部１０３は、弱参照インスタンスの一覧の各要素についてステップＳ６４〜Ｓ６８を繰り返し、全ての弱参照インスタンスについて処理が行われた場合、ステップＳ７０へ進む（Ｓ６９）。ステップＳ６４〜Ｓ６８の繰り返しにより、オブジェクト一時記録領域１０２には、対象のアプリケーションが参照する全てのオブジェクトが記録される。

その後、メモリ使用量計算部１０１は、オブジェクト一時記憶領域１０２に格納されたオブジェクトのヒープメモリ使用量の総和を計算する（Ｓ７０）。尚、メモリ使用量計算部１０１は、オブジェクトの所有する各プリミティブ型の属性の数と参照（オブジェクト）型の属性の数、さらにそのオブジェクトの実装クラスの継承情報に基づいて、Ｊａｖａオブジェクトのメモリ使用量を算出することができる。

図１１は、本発明の実施の形態２にかかる配備アプリケーションが使用するオブジェクトの例を示す図である。例えば、配備アプリケーションであるアプリケーション１２０ａに定義されたクラスから生成されたオブジェクトがオブジェクト１２２ａ１、１２２ａ２、及び１２２ａ３であった場合、アプリケーションａが使用するオブジェクト６００が参照オブジェクト取得部１０３に格納されるオブジェクトとなる。

この場合、アプリケーションサーバ１１０は、弱参照リスト１１４としてオブジェクト１２２ａ１、１２２ａ２、及び１２２ａ３のそれぞれへの弱参照オブジェクトを取得する（Ｓ６２）。そして、アプリケーションサーバ１１０は、ヒープメモリ１０５からオブジェクト１２２ａ１、１２２ａ２、及び１２２ａ３を取得する（Ｓ６４）。その上で、アプリケーションサーバ１１０は、オブジェクト１２２ａ１、１２２ａ２、及び１２２ａ３をオブジェクト一時記憶部１０２に格納する（Ｓ６７）。ここで、参照オブジェクト取得部１０３は、オブジェクト一時記憶部１０２に格納されたオブジェクト１２２ａ１、１２２ａ２、及び１２２ａ３のそれぞれについて、参照されるオブジェクトを再帰的に取得する（Ｓ６８）。ここでは、アプリケーション１２０ａには直接定義されていないオブジェクト６１１〜６１４、６２１〜６２３が取得され、オブジェクト一時記憶部１０２に格納される。尚、アプリケーション１２０ｂのオブジェクト１２２ｂ１及びこれから参照されるオブジェクト６３１及び６３２については、測定対象外として除外される。

以上のことから本実施の形態により、あるアプリケーションが使用する全てのオブジェクトを、アプリケーションクラスローダが生成したオブジェクトから再帰的に参照を辿ってして取得するため、オブジェクトの取りこぼしがなく、アプリケーションのヒープメモリ使用量を正確に算出できる。また、アプリケーションサーバの平常時におけるヒープメモリ算出のための処理が少ないため、アプリケーションサーバへの負荷が少ない。さらに、ヒープメモリ使用量を算出するとき、算出対象の配備アプリケーションで使用するオブジェクトのみ走査し、それ以外の配備アプリケーションやアプリケーションサーバが使用するオブジェクトは算出対象の配備アプリケーションが参照を持たない限り走査しないため、ヒープダンプの出力より短時間でヒープメモリを取得できる。
また、アプリケーションサーバのように、一つのJava VMで複数のアプリケーションが動作している環境で、あるアプリケーションがメモリリーク等を原因にヒープメモリを大量に専有した場合に、他のアプリケーションが受ける影響を抑えることができる。

尚、本実施の形態２は、実施の形態１に加えて、次のような構成を有するものである。すなわち、前記登録手段は、前記ヒープ領域に生成されたオブジェクトへの弱参照オブジェクトを前記オブジェクト特定情報として、当該アプリケーションと対応付けてロードオブジェクト管理情報に登録し、前記第２の取得手段は、前記リストに含まれる各弱参照オブジェクトの参照先である各オブジェクトを前記ヒープ領域から取得するものである。このように、オブジェクト特定情報として弱参照オブジェクトを用いることで、ガーベージコレクションによるオブジェクトの解放への影響を与えない。そのため、本実施の形態を適用することによる不要なメモリ容量確保を回避することができる。

さらに、前記第２の取得手段及び前記第３の取得手段により取得された各オブジェクトを、前記ヒープ領域以外の記憶領域に格納する格納手段をさらに備え、前記算出手段は、前記記憶領域に格納された各オブジェクトのメモリ使用量の総和を前記合計値として算出してもよい。これにより、メモリ使用量の合計値の算出処理を容易にすることができる。

さらにまた、前記第３の取得手段は、前記ヒープ領域のガーベージコレクションにおいてメモリを解放しないオブジェクトを特定する処理と併せて、前記参照される全てのオブジェクトを取得するようにしてもよい。言い換えると、メモリ使用量計算部１０１が行うアプリケーションから参照されるオブジェクトを取得する処理をガベージコレクタ１０６がフルガーベージコレクションを実行する際に実施する、参照オブジェクト（解放しないオブジェクト）をマーキングする処理に相乗りさせても良い。これらにより、ステップＳ６４からＳ６８の繰り返し処理の負荷を軽減することができる。

また、前記算出手段は、複数のアプリケーションについての前記メモリ使用量の合計値を算出する場合、当該複数のアプリケーション間で重複するオブジェクトについてのメモリ使用量の重複分を当該合計値から除くようにしてもよい。これにより、重複分が除かれ、メモリ使用量の精度がより向上する。

また、前記第２の取得手段において前記オブジェクト特定情報により前記ヒープ領域からオブジェクトが特定されない場合に、前記ロードオブジェクト管理情報から当該特定されないオブジェクトを削除する削除手段をさらに備えるようにしてもよい。これにより、管理情報がメンテナンスされ、整合性を保つことができる。

さらに、前記合計値と共に、前記第２の取得手段により取得された各オブジェクトを基点としたオブジェクトの参照関係を出力する出力手段をさらに備えるようにしてもよい。これにより、管理者等による最適なヒープ領域の検討を支援することができる。

また、前記第３の取得手段は、前記取得された各オブジェクトから参照されるオブジェクトを再帰的に取得する。これにより、参照オブジェクトを網羅することができる。

（その他の実施形態）
上述した実施形態２は次のような側面がある。まず、配備アプリケーションで定義するクラスのオブジェクトが生成された時に、そのオブジェクトへの弱参照をマップ上に保持し、弱参照を配備アプリケーションごとに管理するものである。そして、配備アプリケーションで定義するクラスのオブジェクトから、直接的あるいは間接的に参照されるオブジェクトの一覧を取得することで配備アプリケーションのヒープメモリ使用量を計算するものである。

また、次のような側面もある。すなわち、実施形態２は、独自拡張したJVMを用いるものである。このJVMは、アプリケーションサーバ上の各アプリケーションで定義したクラスのオブジェクトが生成されたことを検出する機構と、この機構で検出した生成オブジェクトへの弱参照を保持する機構であるメモリ参照管理空間を持つ。そして、アプリケーションのヒープメモリサイズ取得時には、メモリ参照管理空間に保持する弱参照されたオブジェクトから直接的、あるいは間接的に到達可能なオブジェクトを全て取得する。取得した弱参照されたオブジェクトから到達可能なオブジェクトの一覧から重複を除いて、オブジェクトの総和を取ることでアプリケーションが使用するヒープメモリの総量を計算する。これにより、特定の配備アプリケーションにおけるヒープメモリサイズを取得できる。

また、アプリケーションサーバに複数のアプリケーションが配備された環境において、各配備アプリケーションが使用するヒープメモリサイズを正確に算出することで、運用者がアプリケーションサーバ全体の適切なヒープメモリを見積もることを支援できる。また、メモリリーク発生時に配備アプリケーションごとのメモリ使用量を算出することでリークを起こしている配備アプリケーションを迅速に特定することができる。

さらに、本発明の各実施の形態は、次のような変更が可能である。メモリ使用量計算部１０１のヒープメモリ使用量取得処理の前にガベージコレクションを行ない、予めＪＶＭ内で使用されないオブジェクトを解放しておいてもよい。

上記では独自に拡張したＪＶＭ１００を用いて、オブジェクト生成処理にフックしてアプリケーション内のオブジェクトへの参照を取得していた。しかし、独自に拡張したＪＶＭの代わりに、配備するアプリケーションのオブジェクト生成コード部分にフックイベントを呼び出すコードを埋め込んでも良いものとする。具体的な方法には、別途用意した開発環境で配備アプリケーションをビルドした場合にアプリケーションのソースコードの全ての具象クラスのコンストラクタにフックイベントを呼び出すコードを埋め込んでからコンパイルするなどが挙げられる。

上記図１１では、ある配備アプリケーション（アプリケーションａ）のオブジェクトが別の配備アプリケーション（アプリケーションｂ）のオブジェクトを参照する場合には、ヒープメモリ計算方法として配備アプリケーションｂのオブジェクトを配備アプリケーションａのヒープメモリ使用量に含めずにヒープメモリ計算方法を述べた。但し、これを含めて計算しても良い。この場合、配備アプリケーションごとの動作に必要なヒープメモリの絶対量を測定することが出来る。

また、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、ＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

１ 情報処理装置
１０ ヒープ領域
１１ オブジェクト
２０ ロードオブジェクト管理情報
２１ アプリケーション識別情報
２２ オブジェクト特定情報
３０ 登録手段
４０ 第１の取得手段
５０ 第２の取得手段
６０ 第３の取得手段
７０ 算出手段
２００ 情報処理装置
３００ メモリ
３１０ ヒープメモリ
３１１ オブジェクト
３１２ オブジェクト
３２０ ルートオブジェクト参照表
３２１ クラスローダ情報
３２２ 弱参照オブジェクト
３３０ オブジェクト一時記憶部
３３１ 算出対象オブジェクト
４００ ＣＰＵ
５００ ハードディスク
５１０ ＯＳ
５２０ ＪＶＭ
５２１ オブジェクト生成部
５２２ ガベージコレクタ
５２３ 参照オブジェクト取得部
５２４ メモリ使用量計算部
５３０ アプリケーションサーバ
５３１ 配備部
５４０ アプリケーション
５４１ クラスローダ
５４２ クラス
１００ ＪＶＭ
１０１ メモリ使用量計算部
１０２ オブジェクト一時記憶部
１０３ 参照オブジェクト取得部
１０４ オブジェクト生成部
１０５ ヒープメモリ
１０６ ガベージコレクタ
１１０ アプリケーションサーバ
１１１ 配備部
１１２ ルートオブジェクト参照表
１１３ アプリケーションクラスローダ
１１４ 弱参照リスト
１２０ａ アプリケーション
１２１ａ アプリケーションクラスローダ
１２２ａ１ オブジェクト
１２２ａ２ オブジェクト
１２２ａ３ オブジェクト
１２０ｂ アプリケーション
１２１ｂ アプリケーションクラスローダ
１２２ｂ１ オブジェクト
１２２ｂ２ オブジェクト
１２０ｃ アプリケーション
１２１ｃ アプリケーションクラスローダ
６００ アプリケーションａが使用するオブジェクト
６１１〜６１４、６２１〜６２３、６３１、６３２ オブジェクト

Claims (10)

1. アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する登録手段と、
   所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得する第１の取得手段と、
   前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得する第２の取得手段と、
   前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する第３の取得手段と、
   前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する算出手段と、
   を備える情報処理装置。
2. 前記登録手段は、
   前記ヒープ領域に生成されたオブジェクトへの弱参照オブジェクトを前記オブジェクト特定情報として、当該アプリケーションと対応付けてロードオブジェクト管理情報に登録し、
   前記第２の取得手段は、
   前記リストに含まれる各弱参照オブジェクトの参照先である各オブジェクトを前記ヒープ領域から取得する、
   請求項１に記載の情報処理装置。
3. 前記第２の取得手段及び前記第３の取得手段により取得された各オブジェクトを、前記ヒープ領域以外の記憶領域に格納する格納手段をさらに備え、
   前記算出手段は、前記記憶領域に格納された各オブジェクトのメモリ使用量の総和を前記合計値として算出する
   請求項１又は２に記載の情報処理装置。
4. 前記第３の取得手段は、前記ヒープ領域のガーベージコレクションにおいてメモリを解放しないオブジェクトを特定する処理と併せて、前記参照される全てのオブジェクトを取得する
   請求項１乃至３のいずれか１項に記載の情報処理装置。
5. 前記算出手段は、複数のアプリケーションについての前記メモリ使用量の合計値を算出する場合、当該複数のアプリケーション間で重複するオブジェクトについてのメモリ使用量の重複分を当該合計値から除く
   請求項１乃至４のいずれか１項に記載の情報処理装置。
6. 前記第２の取得手段において前記オブジェクト特定情報により前記ヒープ領域からオブジェクトが特定されない場合に、前記ロードオブジェクト管理情報から当該特定されないオブジェクトを削除する削除手段をさらに備える
   請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記合計値と共に、前記第２の取得手段により取得された各オブジェクトを基点としたオブジェクトの参照関係を出力する出力手段をさらに備える
   請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 前記第３の取得手段は、
   前記取得された各オブジェクトから参照されるオブジェクトを再帰的に取得する
   請求項１乃至７のいずれか１項に記載の情報処理装置。
9. アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録し、
   所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得し、
   前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得し、
   前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得し、
   前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する、
   情報処理装置の制御方法。
10. アプリケーションの実行に応じてヒープ領域にオブジェクトが生成された際に、当該オブジェクトを特定するオブジェクト特定情報を、当該アプリケーションの識別情報と対応付けてロードオブジェクト管理情報に登録する処理と、
    所定の契機により、所定のアプリケーションの識別情報に対応付けられた前記オブジェクト特定情報のリストを前記ロードオブジェクト管理情報から取得する処理と、
    前記リストに含まれる各オブジェクト特定情報により特定される各オブジェクトを前記ヒープ領域から取得する処理と、
    前記取得された各オブジェクトを基点として参照される全てのオブジェクトを取得する処理と、
    前記取得された全てのオブジェクトのメモリ使用量の合計値を算出する処理と、
    をコンピュータに実行させるプログラム。

Images