JP2014078175A

JP2014078175A - 情報処理装置、その制御方法、及びプログラム

Info

Publication number: JP2014078175A
Application number: JP2012226328A
Authority: JP
Inventors: Kunimasa Fujisawa; 邦匡藤澤
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2012-10-11
Filing date: 2012-10-11
Publication date: 2014-05-01
Also published as: US20140108762A1; US9378129B2

Abstract

【課題】アプリケーションが異常動作を行っている可能性の高いタイミングでメモリ情報を取得することにより、アプリケーションの障害調査の効率を向上させる仕組みを提供する。
【解決手段】本情報処理装置は、アプリケーションを実行するために現在使用している使用メモリのサイズと、保存されているアプリケーションが使用するメモリの最大サイズとを比較し、当該比較の結果、使用メモリのサイズが最大サイズ以下であれば、メモリの内容を外部記憶装置へ書き出すダンプ処理を実行せず、使用メモリのサイズが最大サイズより大きければ、当該メモリの内容を外部記憶装置へ書き出すダンプ処理を実行する。
【選択図】図９

Description

本発明は、単一のプロセス上で複数のアプリケーションを動作させる情報処理装置、その制御方法、及びプログラムに関するものである。

現在のＭｕｌｔｉｆｕｎｃｔｉｏｎＰｅｒｉｐｈｅｒａｌ（ＭＦＰ）には、ソリューションの実現のため、ドキュメントのコピーやスキャン、印刷といったＭＦＰに組み込まれた機能以外のアプリケーションを実行する機能を有するものが増えてきている。多くのＭＦＰでは、アプリケーション実行環境としてＪａｖａ（登録商標）の実行環境を有し、Ｊａｖａで記述されたアプリケーションを実行することができる。アプリケーション実行環境の例としては、キヤノンのＭＥＡＰ等が挙げられる。一方、ＰＣ上のＪａｖａアプリケーションの場合には１アプリ１プロセスでアプリケーションを実行するが、ＭＦＰではＣＰＵやメモリの制限のためＯＳＧｉフレームワークなどを使用して１つのＪａｖａのプロセスで複数のアプリケーションを実行するものが多い。そのためＭＦＰ上で実行しているアプリケーションの１つにバグが有りメモリリークを起こしている場合、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生し全てのアプリケーションが停止してしまう可能性がある。

また、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒはアプリケーションがメモリを要求したときに割り当てられるメモリが無かった場合に発生するため、問題のないアプリケーションの実行中に発生し、メモリリークを起こしているアプリケーションを特定することが困難となっていた。メモリリークを発見するためには次の２つの方法がとられてきた。１つはプロファイラというツールを使用しアプリケーションが生成したオブジェクトの状態を監視する方法である。もう１つはＪａｖａＶＭの使用するヒープメモリの内容をダンプし（以下では、ヒープダンプと称する。）アプリケーションが生成したオブジェクトを解析する方法である。特許文献１には、コアダンプ処理が実行できないときに、着脱可能な記憶装置へ接続することによりコアダンプ処理を実現することが提案されている。

特開２００９−１９３５１１号公報

しかしながら、上記従来技術には以下に記載する問題がある。例えば、プロファイラを使用してオブジェクトの状態を監視する場合、アプリケーションの実行速度が極端に低下するためＣＰＵやメモリの制限が大きいＭＦＰへの適用は困難である。一方、従来のヒープダンプは手動により任意のタイミングで実行するものであった。そのためメモリリークしているアプリケーションの特定に最適なＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生する直前にヒープメモリの内容をダンプすることが困難であった。

本発明は、上述の問題に鑑みて行われたものであり、アプリケーションが異常動作を行っている可能性の高いタイミングでメモリ情報を取得することにより、アプリケーションの障害調査の効率を向上させる仕組みを提供することを目的とする。

本発明は、情報処理装置であって、アプリケーションを実行する実行手段と、前記実行手段によって前記アプリケーションを実行する際に該アプリケーションが使用する最大のメモリサイズを示す最大サイズを保存する保存手段と、前記アプリケーションによるメモリ要求を受け付ける受付手段と、前記受付手段によってメモリ要求を受け付けると、該アプリケーションを実行するために現在使用している使用メモリのサイズと、前記保存手段に保存されている該アプリケーションが使用するメモリの前記最大サイズとを比較する比較手段と、前記比較手段の比較の結果、前記使用メモリのサイズが前記最大サイズ以下であれば、メモリの内容を外部記憶装置へ書き出すダンプ処理を実行せず、前記使用メモリのサイズが前記最大サイズより大きければ、該メモリの内容を該外部記憶装置へ書き出すダンプ処理を実行するメモリ管理手段とを備えることを特徴とする。

本発明は、アプリケーションが異常動作を行っている可能性の高いタイミングでメモリ情報を取得することにより、アプリケーションの障害調査の効率を向上させる仕組みを提供できる。

画像処理装置の構成例を示す図。画像処理装置のソフトウェア構成例を示す図。一般的な画像処理装置の構成例を示す図。アプリケーションプログラムファイル構成例を示す図。アプリケーションを起動する際の起動処理のフローチャート。使用メモリ量宣言テーブルの構成例を示す図。ＪａｖａＶＭの通常のオブジェクト生成処理のフローチャート。第１の実施形態の画像処理装置の構成例を示す図。第１の実施形態のオブジェクト生成処理のフローチャート。第２の実施形態の画像処理装置の構成例を示す図。第２の実施形態のメモリ増加量記録処理のプローチャート。第２の実施形態のオブジェクト生成処理のフローチャート。第３の実施形態の画像処理装置の構成例を示す図。第３の実施形態のオブジェクト生成処理のフローチャート。

以下、本発明を実施するための形態について図面を用いて説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものでなく、また実施形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。

＜画像処理装置の構成＞
まず、図１を参照して、ＭＦＰ等の画像処理装置のハードウェア構成例について説明する。なお、以下では、本発明に係る情報処理装置の一例として、画像処理装置１００を用いて説明する。画像処理装置１００は、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、外部記憶装置１０４、ＵＳＢＨＩ／Ｆ制御部１０５、スキャナＩ／Ｆ制御部１０６、プリンタＩ／Ｆ制御部１０７、ＮＶＲＡＭ（不揮発性メモリ）１０８、パネル制御部１０９、ネットワークＩ／Ｆ制御部１１０、スキャナ１１１、プリンタ１１２、及び操作パネル１１３を備える。

ＣＰＵ１０１は、画像処理装置のソフトウェアプログラムを実行し、装置全体を統括的に制御する。ＲＯＭ１０２は、リードオンリメモリであり、装置のブートプログラムや固定パラメータ等が格納されている。ＲＡＭ１０３は、ランダムアクセスメモリであり、ＣＰＵ１０１が装置を制御する際に、一時的なデータの格納などに使用する。外部記憶装置１０４は、インストールされたアプリケーションやアプリケーションのデータや印刷データの格納など、様々なデータの格納に使用する。

ＵＳＢＨＩ／Ｆ制御部１０５はＵＳＢホストインタフェースを制御するためのものであり、様々なＵＳＢデバイスとの通信を制御する。スキャナＩ／Ｆ制御部１０６は、スキャナ１１１を制御する装置である。プリンタＩ／Ｆ制御部１０７は、プリンタ１１２を制御する装置である。

ＮＶＲＡＭ１０８は、不揮発性のメモリでありアプリケーション管理装置の各種設定値が保存される。パネル制御部１０９は、操作パネル１１３を制御し、各種情報の表示、ユーザからの指示入力を行なうためのものである。ネットワークＩ／Ｆ制御部１１０は、ネットワーク１０１とのデータの送受信を制御する。バス１１４には、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、外部記憶装置１０４、ＵＳＢＨＩ／Ｆ制御部１０５、スキャナＩ／Ｆ制御部１０６、プリンタＩ／Ｆ制御部１０７、ＮＶＲＡＭ１０８、パネル制御部１０９、ネットワークＩ／Ｆ制御部１１０が接続される。またバス１１４は、ＣＰＵ１０１からの制御信号や各装置間のデータ信号が送受信されるシステムバスである。ＩＣカードリーダ１１６は、認証を行うためのＵＳＢデバイスである。

＜制御構成＞
次に、図２を参照して、一般的な画像処理装置の制御構成例について説明する。ハードウェア２０１はアプリケーション管理装置のソフトウェアを実行する。ＯＳ（オペレーティングシステム）２０２はプロセスの管理、メモリ管理、入出力管理を実行する。Ｎａｔｉｖｅアプリ２０３はコピー等、機器の基本的な機能を実現するプログラムである。

画像処理装置のソフトウェア２００は、ＪａｖａＶＭ２０４とプリケーションプラットフォーム２０５とから構成される。ＪａｖａＶＭ２０４は、Ｊａｖａプログラムを実行する仮想マシンである。アプリケーションプラットフォーム２０５は、単一のＪａｖａＶＭ上で少なくとも一つ以上のアプリケーションプログラムの起動、停止、インストール、アンインストールといったアプリのライフサイクルの管理を行うプログラムである。アプリＡ２０６、アプリＢ２０７は、アプリケーションプラットフォーム２０５上で動作するアプリケーションプログラムである。ＪａｖａＶＭ２０４から、アプリケーションプラットフォーム２０５及びアプリＡ２０６、アプリＢ２０７は、１つのＪａｖａアプリケーション２０８として処理される。

＜モジュール構成＞
次に、図３を参照して、一般的な画像処理装置のソフトウェア２００におけるモジュール構成について説明する。図２に示したように、ソフトウェア２００は、アプリケーションプラットフォーム２０５と、ＪａｖａＶＭ２０４とを含む。ＪａｖａＶＭ２０４は、バイトコード実行部３０１、メモリ管理部３０２、及びヒープメモリ３０６を備える。

バイトコード実行部３０１は、Ｊａｖａのプログラムコードであるバイトコードを解釈、実行する。ヒープメモリ３０６は、ＪａｖａＶＭが管理する、動的に確保可能なメモリ領域であり、Ｊａｖａプログラムの実行によって生成されたＪａｖａオブジェクトを保持する。メモリ管理部３０２はアプリケーションの使用するメモリの管理を行う。

メモリ管理部３０２は、オブジェクト生成部３０３、ＧＣ実行部３０４、及び使用メモリ量宣言取得部３０５から構成される。オブジェクト生成部３０３は、バイトコード実行部３０１で実行されるプログラムコードの指示に従ってＪａｖａのオブジェクトの生成を行う。ＧＣ部３０４は、ヒープメモリ３０６に保存されているＪａｖａオブジェクトのうち使用されなくなったものを削除するガーベージコレクションを実行する。使用メモリ量宣言取得部３０５は、使用メモリ量宣言テーブル３０８からアプリケーションが使用すると宣言しているメモリの合計値を取得する。

アプリケーションプラットフォーム２０５は、アプリケーション管理部３０７と使用メモリ量宣言テーブル３０８から構成される。アプリケーション管理部３０７は、アプリケーション２０６、２０７のインストール、起動、停止、アンインストールといったアプリケーションのライフサイクルの管理を行う。使用メモリ量宣言テーブル３０８は、アプリケーションプラットフォーム上で実行されているアプリケーションが使用すると宣言しているメモリのサイズを保持する。

＜プログラムファイル＞
次に、図４を参照して、Ｊａｖａアプリケーションのプログラムファイル４０１について説明する。プログラムファイル４０１は、プログラムの情報を記述するマニフェスト部４０２とバイトコード４０３とから構成される。マニフェスト部４０２には、アプリケーションの識別子４０４、バージョンやアプリケーションが使用する最大メモリ量４０３等が記述されている。

＜起動処理＞
次に、図５を参照して、アプリケーション管理部３０７がアプリケーションを起動する際の起動処理について説明する。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２に格納された制御プログラム等をＲＡＭ１０３において実行することにより実現される。

ユーザからアプリケーションの起動指示が実行されると起動処理が開始される。Ｓ５０２において、アプリケーション管理部３０７は、外部記憶装置１０４から起動が指示されたアプリケーションのプログラムファイル４０１をロードする。続いて、Ｓ５０３において、アプリケーション管理部３０７は、ロードしたプログラムファイル４０１からマニフェスト部４０２を取得する。その後、Ｓ５０４において、アプリケーション管理部３０７は、取得したマニフェスト部４０２に記述されているＭａｘＭｅｍｏｒｙＵｓａｇｅの値を取得する。

次に、Ｓ５０５において、アプリケーション管理部３０７は、ＭａｘＭｅｍｏｒｙＵｓａｇｅ情報が取得できたか否かを判定する。取得できればＳ５０６に進み、取得できなければＳ５１１に進む。Ｓ５１１において、アプリケーション管理部３０７は、ＭａｘＭｅｍｏｒｙＵｓａｇｅ情報が取れないため、正常なアプリケーションではないとして、アプリケーションの起動に失敗したと判断し、起動エラーを発行して処理を終了する。

Ｓ５０６において、アプリケーション管理部３０７は、使用メモリ量宣言テーブル３０８から現在起動しているアプリケーションの使用メモリ量宣言の合計値を取得する。続いて、Ｓ５０７において、アプリケーション管理部３０７は、Ｓ５０４で取得したＭａｘＭｅｍｏｒｙＵｓａｇｅの値と、Ｓ５０６で取得した使用メモリ量宣言の合計値の和とＪａｖａＶＭ２０４の管理するヒープメモリ３０６のサイズとを比較する。合計値がヒープメモリ３０６のサイズを超えていなければＳ５０８に遷移し、超えていればＳ５１１に遷移してアプリケーションの起動に失敗したと判断し、起動エラーを発行して処理を終了する。

Ｓ５０８において、アプリケーション管理部３０７は、マニフェスト部４０２に記述されているアプリ識別情報であるＡｐｐ−ＩＤの値を取得する。続いて、Ｓ５０９において、アプリケーション管理部３０７は、Ｓ５０８で取得したＡｐｐ−ＩＤの値と、Ｓ５０４で取得したＭａｘＭｅｍｏｒｙＵｓａｇｅ情報とを、使用メモリ量宣言テーブル３０８に保存する。さらに、Ｓ５１０において、アプリケーション管理部３０７は、アプリケーションの実行を開始し、アプリケーション開始処理を終了する。

＜使用メモリ量宣言テーブル＞
次に、図６を参照して、使用メモリ量宣言テーブル３０８について説明する。使用メモリ量宣言テーブル３０８は、アプリ識別子６０１と、各アプリにおける最大使用メモリ６０２のテーブルと、最大使用メモリの合計値６０３とから構成される。ここでは、アプリＡ及びアプリＢの２つのアプリケーションが管理されており、それぞれの最大使用メモリ６０２が４０ＭＢであるため、合計値６０３は８０ＭＢとなっている。

＜ＪａｖａＶＭのガーベージコレクション＞
ここで、ＪａｖａＶＭのガーベージコレクションについて説明する。一般的にＪａｖａＶＭは高速化のため世代別メモリ管理という手法をとる。これはＪａｖａのメモリをＮｅｗ領域とＯｌｄ領域に二分し、ライフサイクル上、短命のオブジェクトをＮｅｗ領域に長命のオブジェクトをＯｌｄ領域に格納するものである。合わせて、これらの領域から不要になったオブジェクトを削除し、メモリ解放するための機構としてＧＣ実行部３０４を備えている。このＧＣのアルゴリズムにも複数の種類が存在し、Ｎｅｗ領域の不足がＧＣ起点になる場合はＳｃａｖｅｎｇｅＧＣと呼ばれる処理方式、Ｏｌｄ領域の不足が起点となる場合はＦｕｌｌＧＣと呼ばれる処理方式が利用されている。

Ｎｅｗ領域は一般にＯｌｄ領域よりも容量が小さいため、Ｎｅｗ領域のみを対象とするＳｃａｖｅｎｇｅＧＣは高速に実行される。一方、大容量のＯｌｄ領域を対象とするＦｕｌｌＧＣは大量の空きメモリを確保できる可能性があるが実行速度は低速である。

ＳｃａｖｅｎｇｅＧＣとＦｕｌｌＧＣ、Ｎｅｗ領域とＯｌｄ領域の使い分けはあくまでも一例であり、小容量高速なＧＣと大容量低速なＧＣの組み合わせによるパフォーマンスチューニングの方法はこの方法に限定されるものではない。

＜オブジェクト生成処理＞
次に、図７を参照して、通常のＪａｖａＶＭでのオブジェクト生成処理（メモリ要求）について説明する。ＪａｖａＶＭでガーベージコレクションが発生するタイミングの１つとしてオブジェクト生成時が挙げられる。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２に格納された制御プログラム等をＲＡＭ１０３において実行することにより実現される。

まず、アプリケーションのオブジェクト生成のバイトコードがバイトコード実行部３０１で実行されると、オブジェクト生成部３０３は、ヒープメモリのＮｅｗ領域に対してオブジェクトを生成するのに必要なサイズのメモリ要求を行う。メモリ管理部３０２が当該メモリ要求を受け付けると、以下の処理が開始される。したがって、ここでは、メモリ管理部３０２が受付手段の一例として動作する。

Ｓ７０２において、オブジェクト生成部３０３は、空きメモリがあるかを調べ、必要な空きメモリがあればＳ７０７に遷移し、空きメモリを使用してオブジェクトを生成し、処理を終了する。一方、空きメモリが無ければＳ７０３に遷移する。Ｓ７０３において、ＧＣ部３０４は、Ｎｅｗ領域に対してＳｃａｖｅｎｇｅＧＣを実行する。

次に、Ｓ７０４において、オブジェクト生成部３０３は、Ｎｅｗ領域に必要な空きメモリがあるかを調べ、必要な空きメモリがあればＳ７０７に遷移し、空きメモリを使用してオブジェクトを生成し、処理を終了する。一方、空きメモリが無ければＳ７０５に遷移する。Ｓ７０５において、ＧＣ部３０４は、Ｏｌｄ領域に対してＦｕｌｌＧＣを実行する。

次に、Ｓ７０６において、オブジェクト生成部３０３は、Ｏｌｄ領域に必要な空きメモリがあるかを調べ、必要な空きメモリがあればＳ７０７に遷移し、空きメモリを使用してオブジェクトを生成し、処理を終了する。一方、空きメモリが無ければＳ７０８に遷移し、オブジェクト生成部３０３は、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを発生させ、処理を終了する。

＜第１の実施形態＞
以下では、図８及び図９を参照して、本実施形態において特有の構成及び制御について説明する。なお、図１乃至図７で説明したことと異なる部分について主に説明する。まず、図８を参照して、本実施形態の画像処理装置のソフトウェア２００を構成するモジュール構成例について説明する。

図８に示すＪａｖａＶＭ２０４は、図３に示す構成に加えてヒープダンプ部８０１をさらに含むメモリ管理部３０２を有する。ヒープダンプ部８０１は、ヒープメモリの内容を外部記憶装置１０４にファイルとして書きだす処理を実行する。

次に、図９を参照して、本実施形態に係るＪａｖａＶＭ２０４でのオブジェクト生成処理（メモリ要求）について説明する。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２に格納された制御プログラム等をＲＡＭ１０３において実行することにより実現される。なお、図７と同様の処理については、同一のステップ番号を付し、説明を省略する。即ち、以下では、Ｓ７０５の処理に続いて実行されるＳ９０１乃至Ｓ９０４の処理について説明する。

Ｓ７０５でＯｌｄ領域に対してＦｕｌｌＧＣを実行すると、Ｓ９０１に進み、メモリ管理部３０２は、現在使用しているヒープメモリのサイズを取得する。さらに、Ｓ９０２において、使用メモリ量宣言取得部３０５は、使用メモリ量宣言テーブル３０８から最大使用メモリの合計値６０３を取得する。

次に、Ｓ９０３において、メモリ管理部３０２は、Ｓ９０１で取得した現在使用しているヒープメモリのサイズと、Ｓ９０２で取得した最大使用メモリの合計値（規定最大サイズ）とを比較する。使用しているヒープメモリ３０６の最大サイズ以下であればＳ７０６に遷移する。一方、使用しているヒープメモリ３０６の最大サイズよりも大きければ、アプリケーションがメモリリークなどの問題を持っている可能性があるとしてＳ９０４に遷移する。Ｓ９０４において、ヒープダンプ部８０１は、ヒープダンプ（ダンプ処理）を実行し、Ｓ７０６に遷移する。

ここでは、Ｓ９０１で取得した使用ヒープメモリサイズとＳ９０２で取得した最大使用メモリの合計値を直接比較しているが、あくまでも一例であり、Ｓ９０２で取得した最大使用メモリの合計値を引数とする特定の関数の返値と使用しているヒープメモリのサイズを比較してもよい。

その後、Ｓ７０６において、メモリ管理部３０２は、Ｏｌｄ領域に必要な空きメモリがあるかを調べ、必要な空きメモリがあればＳ７０７に遷移する。Ｓ７０７において、メモリ管理部３０２は、オブジェクト生成部３０３によって空きメモリを使用してオブジェクトを生成し、処理を終了する。一方、空きメモリが無ければＳ７０８に遷移し、メモリ管理部３０２は、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ（エラー出力）を発生させ、処理を終了する。

つまり、本実施形態では、Ｓ９０３の判定で使用メモリサイズが規定最大サイズを超えていれば、当該アプリケーションにおいてメモリリーク等の問題が発生している可能性が高いと判断して、ヒープメモリ３０６のヒープダンプを実行する。これにより、本実施形態によれば、アプリケーションに問題が発生している可能性が高いと判断したタイミングでのヒープメモリのヒープダンプを実行することができる。よって、最適なタイミングのヒープダンプの結果を解析することができ、アプリケーションの障害調査の効率を向上させることができる。

＜第２の実施形態＞
以下では、図１０乃至図１２を参照して、本発明の第２の実施形態について説明する。なお、以下では、上記第１の実施形態と異なる部分についてのみ説明する。まず、図１０を参照して、本発明の画像処理装置のソフトウェア２００を構成するモジュール構成例について説明する。図１０に示すように、本実施形態に係るメモリ管理部３０２は、図８の構成に加えて、アプリケーションごとのヒープメモリの変化量を記録するヒープメモリ変化量記録部１００１を備える。ヒープメモリ変化量記録部１００１の処理については以下で図１１を参照して詳細に説明する。

図１１は、ヒープメモリ変化量記録部１００１がヒープメモリの変化量を記録する際の処理手順と、ヒープメモリ変化量記録部１００１が有するヒープメモリの変化量を記録する長さ２の配列１１０１とを示す。ヒープメモリ変化量記録部１００１は、例えば、スレッドとして実装されうる。

メモリ変化量記録処理が開始されると、Ｓ１１０３において、ヒープメモリ変化量記録部１００１は、対象となるアプリケーションが使用しているヒープメモリのサイズを取得する。続いて、Ｓ１１０４において、ヒープメモリ変化量記録部１００１は、Ｓ１１０３で取得した値を配列１１０１の添え字Ｉｎｄｅｘで示される要素に保存する。

次に、Ｓ１１０５において、ヒープメモリ変化量記録部１００１は、保存する配列１１０１のＩｎｄｅｘを更新する「Ｉｎｄｅｘ＝（Ｉｎｄｅｘ＋１）％２」。その後、Ｓ１１０６において、ヒープメモリ変化量記録部１００１は、予め定められた時間スリープして、ヒープメモリ変化量記録処理を終了する。ヒープメモリ変化量記録部１００１は、ヒープメモリ変化量記録処理を終了後すぐに次のヒープメモリ変化量記録処理を開始する。つまり、ヒープメモリ変化量記録部１００１は、定期的に使用ヒープメモリ量（使用量）を取得しておく。

次に、図１２を参照して、本実施形態のＪａｖａＶＭ２０４でのオブジェクト生成処理（メモリ要求）について説明する。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２に格納された制御プログラム等をＲＡＭ１０３において実行することにより実現される。なお、図９と同様の処理については、同一のステップ番号を付し、説明を省略する。即ち、以下では、Ｓ９０３の処理に続いて実行されるＳ１２０１乃至Ｓ１２０８の処理について説明する。

Ｓ９０３において、メモリ管理部３０２は、Ｓ９０１で取得した現在使用しているヒープメモリのサイズとＳ９０２で取得した最大使用メモリの合計値とを比較する。ここで、使用しているヒープメモリのサイズが小さければＳ７０６に遷移する。一方、使用しているヒープメモリのサイズが大きければ、アプリケーションがメモリリークなどの問題を持っている可能性があるとしてＳ１２０１に遷移する。ここでは、Ｓ９０１で取得した使用ヒープメモリサイズとＳ９０２で取得した最大使用メモリの合計値を直接比較している。しかしながら、これはあくまでも一例であり、Ｓ９０２で取得した最大使用メモリの合計値を引数とする特定の関数の返値と使用しているヒープメモリのサイズを比較してもよい。

Ｓ１２０１において、メモリ管理部３０２は、ヒープメモリ変化量記録部１００１からヒープメモリ変化量を取得する。ここで、ヒープメモリ変化量記録部１００１は、Ｓ１２０４乃至Ｓ１２０８の処理を実行し、ヒープメモリ変化量をメモリ管理部３０２へ返す。具体的には、ヒープメモリ変化量取得要求を受け取ると、Ｓ１２０４において、ヒープメモリ変化量記録部１００１は、Ｉｎｄｅｘの値を変数ＴｍｐＩｎｄｅｘにコピーする。続いて、Ｓ１２０５において、ヒープメモリ変化量記録部１００１は、配列１１０１の添字ＴｍｐＩｎｄｅｘの値を取得する。

Ｓ１２０６において、ヒープメモリ変化量記録部１００１は、Ｉｎｄｅｘ＝（Ｉｎｄｅｘ＋１）％２の計算を実行し、Ｉｎｄｅｘの値を更新する。続いて、Ｓ１２０７において、ヒープメモリ変化量記録部１００１は、配列１１０１の添字ＴｍｐＩｎｄｅｘの値を取得する。

その後、Ｓ１２０８において、ヒープメモリ変化量記録部１００１は、［Ｓ１２０５で取得した値］−［Ｓ１２０７で取得した値］で導出した変化量をオブジェクト生成部３０３に返し、ヒープメモリ変化量取得処理を終了する。

Ｓ１２０２において、メモリ管理部３０２は、Ｓ１２０１で取得したヒープメモリ変化量と特定の値（規定サイズ）とを比較する。特定の値以下であればＳ７０６に遷移する。特定の値より大きければＳ９０４に遷移する。本実施形態において、特定の値は、オブジェクト生成コードが暴走していると経験的に決定された値であるが、他の条件から決まる値であってもよい。

以上説明したように、本実施形態によれば、ヒープメモリの変化量を記録し、記録した変化量に応じて、ヒープダンプを実行するか否かを決定する。具体的には、変化量が特定の値よりも大きければ、当該アプリケーションにおいてメモリリーク等の問題が発生している可能性が高いと判断して、ヒープダンプを実行する。これにより、本実施形態によれば、アプリケーションに問題が発生している可能性が高いと判断したタイミングでのヒープメモリのヒープダンプを実行することができる。よって、最適なタイミングのヒープダンプの結果を解析することができ、アプリケーションの障害調査の効率を向上させることができる。

＜第３の実施形態＞
以下では、図１３及び図１４を参照して、本発明の第３の実施形態について説明する。まず、図１３を参照して、本実施形態に係る画像処理装置のソフトウェア２００におけるモジュール構成について説明する。図１３に示すように、本実施形態に係るメモリ管理部３０２は、図８の構成に加えてタスク占有度取得部１３０１を有する。また、ＪａｖａＶＭ２０４は、さらに、Ｊａｖａアプリケーションの生成したスレッドを管理するスレッド管理部１３０２を有する。

バイトコード実行部３０１でスレッドの生成が行われると、そのスレッドに対応するタスクの情報をスレッド管理部１３０２に追加する。また、スレッドの消滅が行われるとそのスレッドに対応するタスクの情報をスレッド管理部１３０２から削除する。タスク占有度取得部１３０１は、ＯＳ２０２からタスクの情報を取得し、スレッド管理部１３０２に保存されているタスク占有度のうち、最大のものを返す。ここで、タスク占有度とは、当該タスクに関する処理がＣＰＵ１０１の動作に占める割合を示す。本実施形態によれば、タスク占有度取得部１３０１が返すタスク占有度は、Ｊａｖａアプリケーションのスレッドに対応するタスクのうち最大のものであるが、占有度上位のＪａｖａアプリケーションのスレッドに対応するタスクの占有度の合計であってもよい。

次に、図１４を参照して、本実施形態のＪａｖａＶＭ２０４でのオブジェクト生成処理（メモリ要求）について説明する。のフローチャートである。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２に格納された制御プログラム等をＲＡＭ１０３において実行することにより実現される。なお、図９と同様の処理については、同一のステップ番号を付し、説明を省略する。即ち、以下では、Ｓ９０３の処理に続いて実行されるＳ１４０１及びＳ１４０２の処理について説明する。

Ｓ９０３において、メモリ管理部３０２は、Ｓ９０１で取得した現在使用しているヒープメモリのサイズとＳ９０２で取得した最大使用メモリの合計値を比較する。ここで、使用しているヒープメモリのサイズが小さければＳ７０６に遷移する。一方、使用しているヒープメモリのサイズが大きければ、アプリケーションがメモリリークなどの問題を持っている可能性があるとしてＳ１４０１に遷移する。ここでは、Ｓ９０１で取得した使用ヒープメモリサイズとＳ９０２で取得した最大使用メモリの合計値を直接比較している。しかしながら、これはあくまでも一例であり、Ｓ９０２で取得した最大使用メモリの合計値を引数とする特定の関数の返値と使用しているヒープメモリのサイズを比較してもよい。

Ｓ１４０１において、メモリ管理部３０２は、タスク占有度取得部１３０１からＪａｖａプログラムに関連付けられたタスクのタスク占有度を取得する。続いて、Ｓ１４０２において、メモリ管理部３０２は、Ｓ１４０１で取得したタスク占有度が特定の値を超えているかを判定する特定の値以下であればＳ７０６に遷移する。一方、特定の値より大きければＳ９０４に遷移する。本実施形態において、特定の値はオブジェクト生成を行うＪａｖａプログラムが暴走していると経験的に決定された値であるが、他の条件から決まる値であってもよい。

以上説明したように、本実施形態によれば、タスクのタスク占有度に応じて、ヒープダンプを実行するか否かを決定する。具体的には、タスク占有度が特定の値よりも大きければ、当該アプリケーションにおいてメモリリーク等の問題が発生している可能性が高いと判断して、ヒープダンプを実行する。これにより、本実施形態によれば、アプリケーションに問題が発生している可能性が高いと判断したタイミングでのヒープメモリのヒープダンプを実行することができる。よって、最適なタイミングのヒープダンプの結果を解析することができ、アプリケーションの障害調査の効率を向上させることができる。

＜その他の実施例＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims

情報処理装置であって、
アプリケーションを実行する実行手段と、
前記実行手段によって前記アプリケーションを実行する際に該アプリケーションが使用する最大のメモリサイズを示す最大サイズを保存する保存手段と、
前記アプリケーションによるメモリ要求を受け付ける受付手段と、
前記受付手段によってメモリ要求を受け付けると、該アプリケーションを実行するために現在使用している使用メモリのサイズと、前記保存手段に保存されている該アプリケーションが使用するメモリの前記最大サイズとを比較する比較手段と、
前記比較手段の比較の結果、前記使用メモリのサイズが前記最大サイズ以下であれば、メモリの内容を外部記憶装置へ書き出すダンプ処理を実行せず、前記使用メモリのサイズが前記最大サイズより大きければ、該メモリの内容を該外部記憶装置へ書き出すダンプ処理を実行するメモリ管理手段と
を備えることを特徴とする情報処理装置。
前記アプリケーションが使用している前記メモリの変化量を記録する記録手段をさらに備え、
前記メモリ管理手段は、
前記使用メモリのサイズが前記最大サイズより大きく、かつ、前記記録手段に記録された前記メモリの変化量が規定のサイズより大きい場合にのみ、該メモリの内容を該外部記憶装置へ書き出すダンプ処理を実行することを特徴とする請求項１に記載の情報処理装置。
前記記録手段は、
前記アプリケーションが使用している前記メモリの使用量を定期的に記録し、異なるタイミングの使用量を比較することで前記変化量を導出することを特徴とする請求項２に記載の情報処理装置。
前記情報処理装置を統括的に制御する制御手段と、
前記アプリケーションを実行させるための処理が、前記制御手段の動作に占める割合を示す占有度を取得する取得手段をさらに備え、
前記メモリ管理手段は、
前記使用メモリのサイズが前記最大サイズより大きく、かつ、前記取得手段によって取得された前記占有度が規定のサイズより大きい場合にのみ、該メモリの内容を該外部記憶装置へ書き出すダンプ処理を実行することを特徴とする請求項１に記載の情報処理装置。
前記取得手段は、
前記制御手段で動作するオペレーティングシステムから当該アプリケーションに関連付けられたタスクの占有度を取得することを特徴とする請求項４に記載の情報処理装置。
前記メモリ管理手段は、さらに、前記受付手段によって受け付けたメモリ要求において要求されたメモリサイズが前記メモリにおいて確保できない場合に、エラー出力を行うことを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。
前記アプリケーションは、Ｊａｖａアプリケーションであり、
前記メモリは、ヒープメモリであることを特徴とする請求項１乃至６の何れか１項に記載の情報処理装置。
情報処理装置の制御方法であって、
実行手段が、アプリケーションを実行する実行ステップと、
保存手段が、前記実行ステップにおいて前記アプリケーションを実行する際に該アプリケーションが使用する最大のメモリサイズを示す最大サイズを保存する保存ステップと、
受付手段が、前記アプリケーションによるメモリ要求を受け付ける受付ステップと、
比較手段が、前記受付ステップにおいてメモリ要求を受け付けると、該アプリケーションを実行するために現在使用している使用メモリのサイズと、前記保存手段に保存されている該アプリケーションが使用するメモリの前記最大サイズとを比較する比較ステップと、
メモリ管理手段が、前記比較ステップの比較の結果、前記使用メモリのサイズが前記最大サイズ以下であれば、メモリの内容を外部記憶装置へ書き出すダンプ処理を実行せず、前記使用メモリのサイズが前記最大サイズより大きければ、該メモリの内容を該外部記憶装置へ書き出すダンプ処理を実行するメモリ管理ステップと
を実行することを特徴とする情報処理装置の制御方法。
請求項８に記載された情報処理装置の制御方法における各ステップを、コンピュータに実行させるためのプログラム。