JP2020177424A - 情報処理装置およびその制御方法、並びにプログラム - Google Patents

Abstract

【課題】アプリが動作する動作環境が複数動作可能である情報処理装置において、あるアプリにて問題が発生した際に、他のアプリへの影響を無くす。【解決手段】１または複数のアプリを動作させるための動作環境が複数、動作可能な情報処理装置であって、アプリの動作時における問題の発生を検知する検知手段と、動作している動作環境の中から、前記問題が発生した動作環境を特定する第１の特定手段と、前記第１の特定手段にて特定された動作環境において、前記問題の発生が検知されるまでに動作していた１または複数のアプリを特定する第２の特定手段と、前記第２の特定手段にて特定された１または複数のアプリが、新たな動作環境にて動作するように動作環境の変更を制御する制御手段とを有する。【選択図】 図４

Description

本発明は、情報処理装置およびその制御方法、並びにプログラムに関する。

従来、情報処理装置上で動作するアプリケーションの実行環境としてＪａｖａ（登録商標、以下省略）が広く知られている。この実行環境では、Ｊａｖａ言語で記述されたアプリケーション（以下、アプリ）が、Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（ＪａｖａＶＭ）上で動作する。１つのＪａｖａＶＭ上で複数のアプリを実行した場合、ある１つのアプリで不正な処理により問題が発生すると、同じＪａｖａＶＭ上で動作している他のアプリにも影響が出てしまう。そのため、１つのアプリを１つのＪａｖａＶＭ上で動作させることで、他のアプリに影響を与えないようにする技術が知られている。しかし、ＪａｖａＶＭの起動には資源が必要であるため、アプリ毎に異なるＪａｖａＶＭを動作させると、大量の資源が必要になってしまう。そのため、画像形成装置のようにメモリやＨＤＤなどの使用可能な資源が少ない情報処理装置では、アプリ毎に異なるＪａｖａＶＭを動作させることは難しい。このための解決手段として、特許文献１のように、異なる役割のＪａｖａＶＭを２つのみ起動することで、一方のＪａｖａＶＭ上で動作するアプリの影響がもう一方のＪａｖａＶＭ上で動作するアプリに影響を与えない技術が知られている。

特開２０１１−１９７８２７号公報

従来の方法により、一方のＪａｖａＶＭ上で動作するアプリの不正な処理が、もう一方のＪａｖａＶＭ上で動作するアプリに影響することはなくなる。しかし、従来の方法では、動作している複数のアプリのうちどのアプリが不正な処理を行っているかを特定することは難しいという課題がある。特に、あるアプリが大量のメモリを確保することによって他のアプリがメモリを確保できなくなったときに発生するメモリリーク（Ｊａｖａの場合はＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ）のような場合、原因となっているアプリを特定することが難しい。難しい理由の一つとして、メモリリークが原因でシステムが停止したときに、動作していたアプリを特定したとしても、このアプリがメモリリークの直接の原因となるアプリではないことが挙げられる。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、１または複数のアプリを動作させるための動作環境が複数、動作可能な情報処理装置であって、アプリの動作時における問題の発生を検知する検知手段と、動作している動作環境の中から、前記問題が発生した動作環境を特定する第１の特定手段と、前記第１の特定手段にて特定された動作環境において、前記問題の発生が検知されるまでに動作していた１または複数のアプリを特定する第２の特定手段と、前記第２の特定手段にて特定された１または複数のアプリが、新たな動作環境にて動作するように動作環境の変更を制御する制御手段とを有する。

本発明により、あるアプリにて問題が発生した際に、他のアプリへの影響を無くすことが可能となり、装置全体のセキュリティや堅牢性を向上させることができる。

本願発明の一実施形態に係る画像形成装置のハードウェア構成の例を示す図。 本願発明の一実施形態に係るソフトウェアのモジュール構成の例を示す図。 本願発明の一実施形態に係るＪａｖａＰＦ管理部の詳細を示す図。 本願発明の一実施形態に係る処理のフローチャート。 第１の実施形態に係るアプリの起動ＶＭ変更処理のフローチャート。 本願発明の一実施形態に係るＪａｖａＰＦ管理部の各モジュールのシーケンス図。 本願発明の一実施形態に係る問題アプリを特定するまでの流れを説明するための図。 本願発明の一実施形態に係るアプリの使用資源量を示す図。 第２の実施形態に係るアプリの起動ＶＭ変更処理のフローチャート。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

＜第１の実施形態＞
以下、本発明の第１の実施形態について説明する。なお、本実施形態では、情報処理装置の一例として、画像形成装置を例に挙げて説明するが、これに限定するものではない。画像形成装置としては、ＭＦＰ（Ｍｕｌｔｉ−Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）などが該当する。

［ハードウェア構成］
図１は、本実施形態に係る画像形成装置１００のハードウェア構成の例を示す。画像形成装置１００は、コントローラユニット１１１および操作部１０６を含んで構成される。なお、ここでは、本実施形態に関連する部分のみを示すものとし、画像形成装置１００の機能に応じて更なる部位を備えてよい。コントローラユニット１１１は、ログファイルやデバイス情報の入出力を行うだけではなく、画像形成装置１００全体の制御や、ネットワークを介して外部へのデータ送信の制御も行う。

コントローラユニット１１１は、各種制御プログラムを実行するＣＰＵ１０１を有する。 ＣＰＵ１０１は、ＲＯＭ１０３に記憶されているブートプログラムに基づきシステムを起動する。そして、ＣＰＵ１０１は、起動したシステム上でＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１０４に記憶されている制御プログラムを読み出してＲＡＭ１０２をワークエリアとして所定の処理を実行する。この制御プログラムにより、Ｊａｖａプログラムなどの所定の制御を実行することが可能である。ＨＤＤ１０４には、各種制御プログラムが記憶されるとともに、ログデータに関する全ての設定やネットワーク部１０７が有するすべての通信手段に関する情報を記憶する。

ＣＰＵ１０１には、ＲＡＭ１０２、ＲＯＭ１０３、およびＨＤＤ１０４がシステムバス１１０を介して接続されている。さらに、ＣＰＵ１０１には、操作部Ｉ／Ｆ１０５、ネットワーク部１０７、電源管理部１０９がシステムバス１１０を介して接続されている。操作部Ｉ／Ｆ１０５は、操作部１０６との間のインターフェース部であり、操作部１０６に表示する画像データの操作部１０６への転送、操作部１０６における操作入力により発生した信号のＣＰＵ１０１への転送などを行う。操作部１０６は、画像処理に関する各機能における現在の設定状態、各機能に関する設定情報を入力するための情報入力画面などを表示するための表示部、ユーザが各機能に対する設定情報を入力するキーなどを含む入力部を有する。

ネットワーク部１０７は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０８に接続され、ＬＡＮ１０８を介した情報の入出力を行う。ＬＡＮ回線にｗｅｂサーバや外部装置が接続されている場合は、それらの装置に対してＬＡＮ１０８を介して情報を出力することが可能である。また、ＬＡＮ回線内のプロキシサーバなどを介して、インターネットに接続し、インターネット上のｗｅｂサーバにファイルを送信することも可能である。電源管理部１０９は、画像形成装置１００の電源ＯＦＦと電源ＯＮの管理を行う。なお、ＣＰＵ１０１は、電源ＯＮや電源ＯＦＦを検知した場合、上述のように、ＲＯＭ１０３のブートプログラムやＨＤＤ１０４に記憶されている制御プログラムを実行する。これにより、画像形成装置１００の初期化処理やシャットダウン処理を実行する。

［ソフトウェア構成］
次に、図２を用いて画像形成装置１００のＣＰＵ１０１やＨＤＤ１０４などの各ハードウェア上で動作するソフトウェアのモジュール構成の例を説明する。なお、これらの各モジュールにおける処理は、ＣＰＵ１０１の命令により、ＲＯＭ１０３やＨＤＤ１０４に記憶されているプログラムを読み出し、ＲＡＭ１０２をワークエリアとして所定の処理を実行することで実現している。また、所定の処理を実行することで生成される情報は、ＲＡＭ１０２もしくはＨＤＤ１０４に記憶する。なお、このような各モジュールにおける処理は、以降でも同様であるため、以降では記載を省略する。また、本実施形態では、ＶＭの例としてＪａｖａＶＭ（Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）を例に挙げて説明するが、これに限定するものではない。他のプログラム言語にて実現される動作環境にて、本願発明は適用されてもよい。

ＯＳ２０１は、画像形成装置１００全体のプロセス管理、メモリ管理、入出力管理等を行うモジュールであり、一般的なＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と同様の処理を行う。Ｊａｖａプラットフォーム（ＪａｖａＰＦ）管理部２０２は、Ｊａｖａのプロセスの監視、起動、アプリ動作環境の変更を行うモジュールである。ＪａｖａＰＦ管理部２０２は、図３に示すモジュールから構成される。なお、図２では、プロセスは２つのみしか記載していないが、ＪａｖａＰＦ管理部２０２は、１または複数のプロセスの起動が可能である。また、ＪａｖａＰＦ管理部２０２は、不正な処理により問題を発生させるアプリを、絞り込んで特定する処理を行う。この処理の詳細については、後述する。

プロセスＡ２０３は、ＪａｖａＰＦ管理部２０２により起動されるプロセスである。なお、本実施形態では、プロセスごとに１つのアプリ実行環境が動作することとする。具体的には、１つのプロセスが起動すると、１つのＪａｖａＶＭと１つのアプリプラットフォームが動作することとする。言い換えると、ＪａｖａＰＦ管理部２０２上では、複数のＪａｖａＶＭ２０５が動作可能である。

ＪａｖａＶＭ２０５は、ＨＤＤ１０４に記憶されているＪａｖａバイトコードを実行することでＪａｖａプログラムを動作させる仮想マシンである。また、ＪａｖａＶＭ２０５は、ＪａｖａＰＦ管理部２０２が起動したプロセスＡ２０３上で起動する。ＪａｖａＶＭ２０５は、起動する際に起動オプションを指定して起動することができる。起動オプションとしては、出力するログの内容の変更や、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ（ＯＯＭＥ）発生時のヒープダンプファイルの生成有無の指定などが挙げられるが、これらの値はＨＤＤ１０４に予め記憶されていることとする。

アプリプラットフォーム（アプリＰＦ）２０６は、１つ以上のＪａｖａアプリの起動、停止、インストール、アンインストールといったアプリのライフサイクルを管理するモジュールであり、ＪａｖａＶＭ２０５上で動作する。なお、図２では、アプリＰＦ２０６では２つのアプリ２０７、２０８（アプリ１、アプリ２）が起動しているが、アプリＰＦ２０６は２つ以上のアプリを起動することが可能である。また、アプリＰＦ２０６は、アプリ２０７、２０８が利用するライブラリやサービスを有する。また、アプリＰＦ２０６は、どのアプリがこれまでに動作したかの管理も行う。なお、アプリＰＦ２０６は様々な方法で実現可能であるが、本実施形態ではＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ（ＯＳＧｉ）を用いることとする。このＯＳＧｉは一般的な仕組みであり、ここでの説明は省略する。

アプリ２０７、２０８は、ＪａｖａＶＭ２０５上で動作するＪａｖａプログラムのバイトコードであり、アプリＰＦ２０６が有するライブラリやサービスを利用して動作する。なお、これらのアプリは、他のプロセスのＪａｖａＶＭ上で動作することも可能である。なお、ＪａｖａＰＦ管理部２０２上で動作する他のプロセス（例えば、プロセスＢ２０４）におけるＪａｖａＶＭ、アプリＰＦ、アプリの構成等は、プロセスＡ２０３のものと同様であるため、説明は省略する。なお、アプリごとに提供される機能やサービスは異なっていてよい。

（ＪａｖａＰＦ管理部）
図３は、本実施形態に係るＪａｖａＰＦ管理部２０２の詳細な説明を行うための図である。 ＪａｖａＰＦ管理部２０２は、プロセス制御部３０１、問題特定部３０２、アプリ動作管理部３０３、ＶＭ起動管理部３０４、および資源管理部３０５を含んで構成される。

プロセス制御部３０１は、複数のＪａｖａプロセスの起動や停止などの制御を行う。例えば、図２の例の場合、プロセス制御部３０１は、プロセスＡ２０３とプロセスＢ２０４を起動する。問題特定部３０２は、プロセス制御部３０１で起動したプロセス上で動作するアプリの中で、問題（フリーズやＥｘｃｅｐｔｉｏｎなど）が発生しているアプリを特定するための処理を行う。ここでの問題の内容は特に限定するものでは無い。

アプリ動作管理部３０３は、各アプリを、プロセス制御部３０１で起動した複数のプロセスのＪａｖａＶＭのうちのいずれの上で動作させるかの決定や管理を行うための処理を行う。ＶＭ起動管理部３０４は、資源管理部３０５を用いて、起動可能なＪａｖａＶＭの最大数を決定するための処理を行う。また、ＶＭ起動管理部３０４は、決定した最大数のＪａｖａＶＭを、プロセス制御部３０１を用いて起動するための処理を行う。

資源管理部３０５は、ＪａｖａＶＭを動作させるために必要な資源量（ＪａｖａＶＭ資源量）と、ＪａｖａＰＦ管理部２０２上で動作するアプリが使用するメモリサイズやファイルサイズなどの資源量（アプリ使用資源量）を取得する処理を行う。なお、ＪａｖａＶＭ資源量は予めＨＤＤ１０４に記憶されていることとする。また、アプリ使用資源量はアプリの設定ファイルから取得することとする。アプリの設定ファイルとしては様々なものがあるが、本実施形態では、ＨＤＤ１０４に記憶している各アプリのＭＡＮＩＦＥＳＴファイルを用いる。また、ＭＡＮＩＦＥＳＴファイルには、対応するアプリの最大使用資源量が記載されていることとする。情報処理装置の資源（リソース）は、特に限定されるものでは無いが、例えば、記憶領域のサイズや処理負荷などに応じて対象となるものが変更されてよい。

［処理フロー］
続いて、本実施形態に係るＪａｖａＰＦ管理部２０２の各モジュールにより、アプリの不正な処理により問題が発生した場合に、起動可能な最大数のＪａｖａＶＭを起動し、問題の原因となるアプリを絞り込みながら特定する処理を説明する。図４、図５は、本実施形態の処理に係るフローチャートである。また、図６は、図４、図５の処理フローにおける各モジュール間の連携を示すシーケンス図である。上述したように、各処理は、画像形成装置１００のＣＰＵ１０１がＨＤＤ１０４等に格納されたプログラムを読み出して実行することで実現される。

Ｓ４０１にて、問題特定部３０２は、ＪａｖａＰＦ管理部２０２上で動作しているプロセスの中で、監視対象の問題が発生しているＪａｖａＶＭがあるか否かを判定する。なお、ここでは、問題特定部３０２が定期的に各プロセスの状態を監視することで確認する方法を用いることとするが、これに限定するものではない。例えば、問題が発生したＪａｖａＶＭが問題特定部３０２に通知を行うコールバック形式などの別の方法でもよい。また、ここでのアプリの動作時における問題として判定される内容は、予め定義されているものとする。問題を検知した場合は（Ｓ４０１にてＹＥＳ）Ｓ４０２へ進み、問題を検知していない場合は（Ｓ４０１にてＮＯ）監視が継続される。

Ｓ４０２にて、問題特定部３０２は、題が発生したＪａｖａＶＭを特定する。以下、ここで特定したＪａｖａＶＭを問題発生ＪａｖａＶＭと呼ぶ。

Ｓ４０３にて、問題特定部３０２は、Ｓ４０２にて特定した問題発生ＪａｖａＶＭ上で動作するアプリＰＦに対して、問題発生までに起動したアプリの問い合わせを行い、起動したアプリを特定する。ここで特定されたアプリのいずれかが問題を引き起こしているアプリである。以下、ここで特定したアプリを特定アプリと呼ぶ。

Ｓ４０４にて、問題特定部３０２は、Ｓ４０３にて特定した特定アプリを停止する要求をアプリＰＦに出し、特定アプリを停止させる。

Ｓ４０５にて、問題特定部３０２は、Ｓ４０４の処理により停止したアプリが２つ以上か否かの判定を行う。停止するアプリの数は、例えば、Ｓ４０３における問い合わせの結果に基づいて判定してよい。停止したアプリが１つ以下であると判定された場合は（Ｓ４０５にてＮＯ）Ｓ４１２へ進み、２つ以上であると判定された場合は（Ｓ４０５にてＹＥＳ）Ｓ４０６へ進む。

Ｓ４０６にて、問題特定部３０２は、起動可能なＪａｖａＶＭの最大数（最大ＪａｖａＶＭ数）をＶＭ起動管理部３０４に問い合わせるための要求を送信する（図６のＦ６０１）。上記要求を受信したＶＭ起動管理部３０４は、資源管理部３０５にＪａｖａＰＦ管理部２０２上で動作する全アプリの最大使用資源量（アプリ使用資源量）と、ＪａｖａＶＭ動作に必要な資源量（ＪａｖａＶＭ資源量）の問い合わせ要求を送信する（図６のＦ６０２）。この要求を受信した資源管理部３０５は、ＪａｖａＰＦ管理部２０２上で動作している全プロセスのアプリＰＦに対して、全アプリが動作するのに必要なアプリ資源量の要求を送信する。この要求を受信した各アプリＰＦは、アプリＰＦ上で動作する各アプリのＭＡＮＩＦＥＳＴファイルからアプリ毎の最大使用資源量を抽出し、合計した値を資源管理部３０５に送信する。これを受信した資源管理部３０５は、各プロセスから送信された資源量の合計値を、アプリ使用資源量とする。

Ｓ４０７にて、資源管理部３０５は、ＨＤＤ１０４から１つのＪａｖａＶＭを動作するために必要なＪａｖａＶＭ資源量と、ＪａｖａＰＦ管理部２０２で使用可能なＪａｖａ総資源量を取得する。なお、ＪａｖａＶＭ資源量とＪａｖａ総資源量は、本実施形態では予めＨＤＤ１０４に記憶しておく。そして、資源管理部３０５は、Ｓ４０６にて取得したアプリ使用資源量、ＪａｖａＶＭ資源量、およびＪａｖａ総資源量を、ＶＭ起動管理部３０４へ送信する（図６のＦ６０３）。

Ｓ４０８にて、ＶＭ起動管理部３０４は、Ｓ４０７にて取得したアプリ使用資源量、ＪａｖａＶＭ資源量、およびＪａｖａ総資源量を用いて、最大ＪａｖａＶＭ数を決定する。具体的には、以下の式（１）が成り立つように、最大ＪａｖａＶＭ数Ｎを算出する。
Ｊａｖａ総資源量 ≧ アプリ使用資源量 ＋ ＪａｖａＶＭ資源量×Ｎ …式（１）
この後に、ＶＭ起動管理部３０４は、最大ＪａｖａＶＭ数Ｎを問題特定部３０２に送信する（図６のＦ６０４）。

Ｓ４０９にて、問題特定部３０２は、最大ＪａｖａＶＭ数を受信すると、最大ＪａｖａＶＭ数のＪａｖａＶＭが既に起動しているか否かを判定する。ここでは、ＪａｖａＰＦ管理部２０２上で動作しているプロセス数を調べること起動しているＪａｖａＶＭ数を特定することが可能である。最大ＪａｖａＶＭ数のＪａｖａＶＭがすでに起動していると判定された場合は（Ｓ４０９にてＹＥＳ）Ｓ４１１へ進み、そうでない場合は（Ｓ４０９にてＮＯ）Ｓ４１０へ進む。

Ｓ４１０にて、問題特定部３０２は、最大ＪａｖａＶＭ数になるようにＪａｖａＶＭを起動するためのプロセスの起動要求を、プロセス制御部３０１に送信する（図６のＦ６０５）。この要求を受信したプロセス制御部３０１は、プロセスを起動し、さらにこのプロセス上で動作するＪａｖａＶＭも起動させる。プロセス制御部３０１は、プロセスの起動が完了すると、プロセスの起動完了通知を問題特定部３０２に送信する（図６のＦ６０６）。そして、Ｓ４１１へ進む。

Ｓ４１１にて、問題特定部３０２は、一部のアプリを別のＪａｖａＶＭ上で動作させるために、後述のアプリの起動ＶＭ変更処理を行う。本工程の処理の時点では、最大ＪａｖａＶＭ数のＪａｖａＶＭが起動した状態となっている。本工程の詳細は、図５を用いて説明する。本工程の処理の完了後、Ｓ４０１に戻り、監視を継続する。

Ｓ４１２にて、問題特定部３０２は、停止したアプリが問題の原因であるアプリ（問題アプリ）として特定する。そして、本処理フローを終了する。

（起動ＶＭ変更処理）
図５を用いて、図４のＳ４１１の工程におけるアプリの起動ＶＭ変更処理の詳細について説明する。

Ｓ５０１にて、問題特定部３０２は、図４のＳ４０２で特定した問題発生ＪａｖａＶＭ以外のＪａｖａＶＭ（以下、安全ＪａｖａＶＭ）上で、監視対象アプリが動作しているか否かを判定する。この監視対象アプリは、前回の問題発生時に動作した特定アプリが相当する。監視対象アプリは、後述のＳ５０５の処理にてＨＤＤ１０４に記憶されているものとし、初期の状態では監視対象アプリなしとして扱われるものとする。問題特定部３０２は、ＨＤＤ１０４から取得した監視対象アプリが動作しているＪａｖａＶＭを特定するために、各プロセスのアプリＰＦに問い合わせを行う。この問い合わせ結果に基づき、問題特定部３０２は、監視対象アプリが動作しているＪａｖａＶＭが、安全ＪａｖａＶＭ上で動作しているか否かを判定する。ここで、安全ＪａｖａＶＭ上で監視対象アプリが動作していると判定された場合、これらの監視対象アプリは問題を発生させないアプリであるして扱われる。以下、安全ＪａｖａＶＭ上で動作する監視対象アプリを、監視除外アプリと呼ぶ。安全ＪａｖａＶＭ上で監視対象アプリが動作していると判定された場合（Ｓ５０１にてＹＥＳ）Ｓ５０２へ進み、安全ＪａｖａＶＭ上で監視対象アプリが動作していないと判定された場合（Ｓ５０１にてＮＯ）Ｓ５０４へ進む。

Ｓ５０２にて、問題特定部３０２は、アプリ動作管理部３０３に、監視除外アプリを動作させる安全ＪａｖａＶＭを変更するための要求を送信する（図６のＦ６０７）。この要求を受信したアプリ動作管理部３０３は、監視除外アプリを動作させる安全ＪａｖａＶＭを決定する。この決定方法としては様々な方法があるが、本実施形態では、安全ＪａｖａＶＭの任意の１つを選択し、この選択した安全ＪａｖａＶＭ上で全ての監視除外アプリを動作させることとする。

Ｓ５０３にて、アプリ動作管理部３０３は、Ｓ５０２にて決定した安全ＪａｖａＶＭ上で、監視除外アプリをアプリＰＦによって起動させる。そして、アプリ動作管理部３０３は、問題特定部３０２に監視除外アプリの動作変更要求の完了を送信する（図６のＦ６０８）。

Ｓ５０４にて、問題特定部３０２は、特定アプリを動作させるＪａｖａＶＭを決定する。より詳細には、問題特定部３０２は、アプリ動作管理部３０３に、ＪａｖａＰＦ管理部２０２上で動作しているＪａｖａＶＭの中から、特定アプリを動作させるＪａｖａＶＭを変更するための要求を送信する（図６のＦ６０９）。この要求を受信したアプリ動作管理部３０３は、まず、特定アプリを動作させる候補となるＪａｖａＶＭ（以下、割当候補ＪａｖａＶＭ）を特定する。具体的には、アプリ動作管理部３０３は、起動しているＪａｖａＶＭの中で１つもアプリが動作しないＪａｖａＶＭと、特定アプリが動作していたＪａｖａＶＭを、割当候補ＪａｖａＶＭとする。そして、アプリ動作管理部３０３は、これらの割当候補ＪａｖａＶＭの中から特定アプリを動作させるＪａｖａＶＭを決定する。この決定方法は様々な方法があるが、本実施形態では各割当候補ＪａｖａＶＭ上で動作するアプリ数が均等になるように決定する。例えば、割当候補ＪａｖａＶＭが３個であり、特定アプリが８個の場合は、２つの割当候補ＪａｖａＶＭ上で３つの特定アプリを動作させ、残りの１つの割当候補ＪａｖａＶＭ上で２つの特定アプリを動作させるように決定する。なお、割当候補ＪａｖａＶＭへの割り当ては、アプリの数に基づくものに限定するものではなく、アプリのデータサイズや処理負荷などに基づいて決定してもよい。

Ｓ５０５にて、アプリ動作管理部３０３は、Ｓ５０５で決定した割り当てに基づいて、各割当候補ＪａｖａＶＭ上で特定アプリを、アプリＰＦを用いて起動させる。そしてアプリ動作管理部３０３は、問題特定部３０２に特定アプリのＪａｖａＶＭ動作変更完了を送信する（図６のＦ６１０）。

Ｓ５０６にて、問題特定部３０２は、ＨＤＤ１０４にて保持されていた今までの監視対象アプリの情報をクリアする。ここでのクリアとは、管理アプリ対象を「なし」に変更することを指す。さらに、問題特定部３０２は、Ｓ４０３で特定した特定アプリを、監視対象アプリに設定し、ＨＤＤ１０４にて記憶させる。そして、本処理フローを終了する。

［動作例］
続いて、図４〜図６を用いて説明した本実施形態に係る問題アプリを特定するまでの流れの具体例を、図７を用いて説明する。本例が開始される際の状態として、ＪａｖａＰＦ管理部２０２上では、図７（ａ）のように１つのプロセスＡが動作しており、このプロセスＡでは、アプリ１〜アプリ６の６つのアプリがＪａｖａＶＭ１上で動作していることとする。

（１回目の問題発生時の処理）
まず、図７（ａ）の状態において、プロセスＡのいずれかのアプリにより問題が発生したとする。問題特定部３０２は、各プロセスの状態を確認し、問題が発生したか否かを確認する （図４のＳ４０１）。ここでは、問題特定部３０２は、プロセスＡで問題が発生したことを検知し、ＪａｖａＶＭ１で問題が発生したと特定する（図４のＳ４０２）。そして、問題特定部３０２は、問題発生までに起動したアプリを特定する（図４のＳ４０３）。ここでは、６つのアプリのうち、アプリ１、アプリ２、アプリ４、アプリ５が問題発生までに動作していたこととする。このため、図７（ｂ）に示すように、アプリ１、アプリ２、アプリ４、アプリ５を特定アプリと特定する。以降では、図７（ｂ）のように、特定アプリを四角の点線で囲むことで示す。さらに問題特定部３０２は、特定アプリを停止させる（図４のＳ４０４）。

その後、問題特定部３０２は、停止したアプリが２つ以上であるか否かの判定を行う（図４のＳ４０５）。ここで停止したアプリは４つであるため、問題特定部３０２は、最大ＪａｖａＶＭ数をＶＭ起動管理部３０４に問い合わせるための要求を送信する。これを受信したＶＭ起動管理部３０４は、資源管理部３０５にアプリ使用資源量とＪａｖａＶＭ資源量の問い合わせ要求を送信する。この要求を受信した資源管理部３０５は、アプリＰＦを用いて、アプリ使用資源量とＪａｖａＶＭ資源量を取得する。本実施形態では、使用資源量としてメモリを対象とする。図８は、本例におけるアプリ１〜アプリ６の各アプリのＭＡＮＩＦＥＳＴファイルに記載されている最大使用メモリをまとめたアプリ使用資源管理テーブル８０１の構成例を示す。図８は、アプリ使用資源管理テーブル８０１における番号を表す「Ｎｏ」と、アプリの名称を表す「アプリ名称」と、アプリの最大使用メモリサイズを表す「使用メモリ」を含んで構成される。アプリ使用資源管理テーブル８０１は、ＨＤＤ１０４にて保持・管理される。

資源管理部３０５は、アプリ使用資源管理テーブル８０１を参照し、アプリ使用資源量として１０００ＭＢを特定する（図４のＳ４０６）。さらに資源管理部３０５は、ＨＤＤ１０４から１つのＪａｖａＶＭを動作するために必要なＪａｖａＶＭ資源量と、ＪａｖａＰＦ管理部２０２で利用可能なＪａｖａ総資源量を取得する（図４のＳ４０７）。本例では、ＪａｖａＶＭ資源量は３００ＭＢ、Ｊａｖａ総資源量は２０００ＭＢであることとし、この値は予めＨＤＤ１０４に記憶されていることとする。そして、資源管理部３０５は、アプリ使用資源量、ＪａｖａＶＭ資源量、およびＪａｖａ総資源量をＶＭ起動管理部３０４へ送信する。ＶＭ起動管理部３０４は、アプリ使用資源量、ＪａｖａＶＭ資源量、およびＪａｖａ総資源量を用いて、最大ＪａｖａＶＭ数を決定する（図４のＳ４０８）。上記式（１）に基づき、「２０００ ≧ １０００ ＋ ３００×Ｎ」が成り立つＮは、「３」であるため、資源管理部３０５は、最大ＪａｖａＶＭ数は３であると算出し、この最大ＪａｖａＶＭ数を問題特定部３０２に送信する。

問題特定部３０２は、最大ＪａｖａＶＭ数を受信すると、最大ＪａｖａＶＭ数のＪａｖａＶＭが既に起動しているか否かを確認する（図４のＳ４０９）。この時点では図７（ｂ）に示すように、１つのプロセスＡしか起動していないため、問題特定部３０２は、プロセス制御部３０１を用いて更に２つのプロセスを起動することで、２つのＪａｖａＶＭを起動させる（図４のＳ４１０）。ここでは、更に起動させる２つのＪａｖａＶＭとして、ＪａｖａＶＭ２とＪａｖａＶＭ３を起動することとする。

そして問題特定部３０２は、一部のアプリをＪａｖａＶＭ１とは別のＪａｖａＶＭ上で動作させるために、アプリの起動ＶＭ変更処理を行う（図４のＳ４１１）。まず、問題特定部３０２は、安全ＪａｖａＶＭ上で監視対象アプリが動作しているか否かを判定する（図５のＳ５０１）。この時点では、監視対象アプリは１つもないため、問題特定部３０２は、アプリ動作管理部３０３に、特定アプリを動作させるＪａｖａＶＭを決定するための要求を送信する。

この要求を受信したアプリ動作管理部３０３は、割当候補ＪａｖａＶＭを特定する。ここでは、ＪａｖａＶＭ２とＪａｖａＶＭ３が１つもアプリが動作していないＪａｖａＶＭであり、特定アプリを動作していたのがＪａｖａＶＭ１である。そのため、割当候補ＪａｖａＶＭとして、ＪａｖａＶＭ２、ＪａｖａＶＭ３、ＪａｖａＶＭ１が特定される。アプリ動作管理部３０３は、これらの割当候補ＪａｖａＶＭそれぞれに対し、いずれの特定アプリを動作させるかを決定する（図５のＳ５０４）。ここでは、アプリ１とアプリ４をＪａｖａＶＭ２上で動作させ、アプリ２をＪａｖａＶＭ３上で動作させ、アプリ５をＪａｖａＶＭ３上で動作させることとする。この決定に基づき、アプリ動作管理部３０３は、ＪａｖａＶＭ２上でアプリ１とアプリ４を起動させ、ＪａｖａＶＭ３上でアプリ２を起動させ、ＪａｖａＶＭ１上でアプリ５を起動させる（図５のＳ５０５）。そして、問題特定部３０２は、ＨＤＤ１０４にて管理されていた監視対象アプリの情報をクリアした上で、特定アプリを監視対象アプリに設定するように更新する （図５のＳ５０６）。これにより、図７（ｃ）の状態となる。図７（ｃ）において、Ｓ５０６で決定した監視対象アプリを識別可能に表記し、以降でも同様の表記を行う。その後、図４のＳ４０１の処理に戻り、問題発生の監視が継続される。

（２回目の問題発生時の処理）
続いて、プロセスＡのいずれかのアプリにより問題が発生したとする（図４のＳ４０１）。問題特定部３０２は、プロセスＡのＪａｖａＶＭ２で問題が発生したと特定する（図４のＳ４０２）。そして、問題特定部３０２は、問題発生までに起動したアプリを特定する（図４のＳ４０３）。ここでは、アプリ１とアプリ４が問題発生までに動作していたこととする。このため、アプリ１とアプリ４を特定アプリとみなし、図７（ｄ）の状態となる。さらに、問題特定部３０２は、これらの特定アプリを停止させる （図４のＳ４０４）。

その後、問題特定部３０２は、停止したアプリが２つ以上であるか否かの判定を行う（図４のＳ４０５）。ここで停止したアプリは２つであるため、前述のＳ４０８〜Ｓ４１０により、最大ＪａｖａＶＭ数を特定する。ここでは最大ＪａｖａＶＭ数Ｎは「３」となる。この後に問題特定部３０２は、最大ＪａｖａＶＭ数のＪａｖａＶＭが既に起動しているか否かを確認する（図４のＳ４０９）。ここでは、図７（ｄ）に示すように３つのＪａｖａＶＭが既に起動しているため、アプリの起動ＶＭ変更処理を行う（図４のＳ４１１）。

まず、問題特定部３０２は、安全ＪａｖａＶＭ上で動作している監視除外アプリを判定する（図５のＳ５０１）。ここでは、図７（ｄ）に示すように、ＪａｖａＶＭ３とＪａｖａＶＭ１が安全ＪａｖａＶＭである。また、アプリ２とアプリ５が安全ＪａｖａＶＭ上で動作しているため、これらが監視除外アプリとなる。アプリ動作管理部３０３は、この２つの監視除外アプリをどの安全ＪａｖａＶＭで動作させるかを決定する（図５のＳ５０２）。ここでは、安全ＪａｖａＶＭであるＪａｖａＶＭ１でアプリ２とアプリ５を動作させることとする。アプリ動作管理部３０３は、決定した安全ＪａｖａＶＭ上で監視除外アプリを起動させる（図５のＳ５０３）。これにより、図７（ｅ）の状態となる。つまり、特定アプリ以外のアプリが安全ＪａｖａＶＭに集約されることとなる。この後、アプリ動作管理部３０３は、問題特定部３０２に監視対象アプリの動作変更要求の完了を送信する。

更に問題特定部３０２は、前述のＳ５０４〜Ｓ５０５の処理を行い、特定アプリを複数のＪａｖａＶＭ上に分けて起動させる。まず問題特定部３０２は、アプリ動作管理部３０３に、特定アプリを動作させるＪａｖａＶＭを決定するための要求を送信する。この要求を受信したアプリ動作管理部３０３は、割当候補ＪａｖａＶＭを特定する。本例において、図７（ｅ）に示すように、ＪａｖａＶＭ３が１つもアプリが動作していないＪａｖａＶＭであり、また、ＪａｖａＶＭ２が特定アプリが動作していたＪａｖａＶＭである。そのため、ＪａｖａＶＭ３とＪａｖａＶＭ２を割当候補ＪａｖａＶＭとなる。アプリ動作管理部３０３は、これらの割当候補ＪａｖａＶＭそれぞれ上で、いずれの特定アプリを動作させるかを決定する（図５のＳ５０４）。ここでは、アプリ１をＪａｖａＶＭ２上で動作させ、アプリ４をＪａｖａＶＭ３上で動作させることとする。この決定に基づき、アプリ動作管理部３０３は、ＪａｖａＶＭ２上でアプリ１を起動させ、ＪａｖａＶＭ３上でアプリ４を起動させる（図５のＳ５０５）。そして、問題特定部３０２は、ＨＤＤ１０４にて管理されていた監視対象アプリの情報をクリアした上で、特定アプリを監視対象アプリに設定するように更新する （図５のＳ５０６）。ここでは、アプリ１とアプリ４が新たな監視対象アプリとなる。これにより、図７（ｆ）の状態となる。その後、図４のＳ４０１の処理に戻り、問題発生の監視が継続される。

（３回目の問題発生時の処理）
続いて、プロセスＣのいずれかのアプリにより問題が発生したとする（図４のＳ４０１）。問題特定部３０２は、プロセスＣのＪａｖａＶＭ３で問題が発生したと特定する（図４のＳ４０２）。そして、問題特定部３０２は、問題発生までに起動したアプリを特定する（図４のＳ４０３）。ここでは、アプリ４が問題発生までに動作していたこととする。このため、アプリ４を特定アプリとみなし、図７（ｇ）の状態となる。さらに、問題特定部３０２は、特定アプリを停止させる （図４のＳ４０４）。

その後、問題特定部３０２は、停止したアプリが２つ以上であるか否かの判定を行う（図４のＳ４０５）。ここで停止したアプリは１つであるため、問題特定部３０２は、問題の原因となるアプリは、アプリ４であると特定する（図４のＳ４１２）。

以上、本実施形態により、Ｊａｖａ総資源量、アプリ使用資源量、ＪａｖａＶＭ資源量を考慮して決定した最大ＪａｖａＶＭ数以内のＪａｖａＶＭを起動し、問題の原因となるアプリを特定することができる。これにより、問題発生アプリを他のＪａｖａＶＭとは分けて動作することが可能となり、他のアプリへの影響を無くすことが可能となる。その結果、装置全体のセキュリティや堅牢性を向上させることができる。

上記の説明では、図４のＳ４０８において最大ＪａｖａＶＭ数を決定するために、Ｓ４０６もしくはＳ４０７では、資源としてメモリを用いた。しかし、資源はメモリに限定されるものではなく、使用するファイルサイズ（ファイル容量）、ディスクリプタ数、ソケット数、スレッド数、プロセス数などのメモリ以外の資源を用いてもよい。

また、図４のＳ４１２にて問題アプリを特定したが、この際に、ユーザに通知するような構成であってもよい。例えば、ログに問題アプリの情報を出力してもよいし、画面上に表示してもよい。

また、上記の説明では、図４の処理により問題アプリの絞り込みを行って、特定（隔離）するまでの流れについて示した。更にこの処理の後、問題アプリが存在しない複数のＪａｖａＶＭのいずれかに問題が発生していないアプリをまとめる処理を行ってもよい。具体的には、図７（ｇ）に示す状態では、プロセスＡとプロセスＢには問題アプリは動作していない。そのため、プロセスＡもしくはプロセスＢのいずれかを停止させ、一方のプロセスにて問題アプリ以外のアプリ（ここでは、アプリ１〜３、アプリ５、アプリ６）を動作させるようにしてもよい。これにより資源の節約が可能となる。もしくは、問題が発生する直前において起動していたＪａｖａＶＭの数を記憶しておき、その数に近づくように、問題アプリが動作していないＪａｖａＶＭの数を制御するような構成であってもよい。

＜第２の実施形態＞
第１の実施形態では、割当候補ＪａｖａＶＭは、安全ＪａｖａＶＭと同じ起動オプションで起動する構成について説明した。しかし、問題アプリを一意に特定するまでに時間がかかる場合は、一意に特定する前に、問題発生時のログを開発者が確認することで、問題アプリを特定したい場合がある。このような場合に対応するために、割当候補ＪａｖａＶＭは、安全ＪａｖａＶＭとは異なる起動オプションで起動することで、より詳細なログ（安全ＪａｖａＶＭでは出力しないログ）を自動で出力することが望まれる。

本実施形態では、割当候補ＪａｖａＶＭの起動オプションを自動で変更する構成について説明する。なお、基本的な処理や制御は第１の実施形態と同じであるため、第１の実施形態と異なる点のみを説明する。具体的には、本実施形態では、起動ＶＭ変更処理において割当候補ＪａｖａＶＭの起動オプション変更の処理を行う点が、第１の実施形態とは異なる。

（起動ＶＭ変更処理）
図９を用いて、本実施形態に係る図４のＳ４１１の工程におけるアプリの起動ＶＭ変更処理の詳細について説明する。Ｓ５０１〜Ｓ５０４の処理は、第１の実施形態にて述べた図５の処理と同じである。Ｓ５０４の処理の後、Ｓ９０１にて、問題特定部３０２は、問題発生回数が所定の回数以下であるか否かを判定する。問題発生回数は、デフォルト値は「０」であり、ＨＤＤ１０４に記憶されているものとする。また、所定の回数は、予め定義され、ＨＤＤ１０４に保持されているものとする。問題発生回数が所定の回数以下であると判定された場合（Ｓ９０１にてＹＥＳ）Ｓ５０５へ進み、所定の回数よりも多いと判定された場合は（Ｓ９０１にてＮＯ）Ｓ９０２へ進む。

Ｓ９０２にて、問題特定部３０２は、Ｓ５０４で決定した割当候補ＪａｖａＶＭの起動時のオプションを、安全ＪａｖａＶＭとは異なる起動オプションに変更する。本実施形態では、問題アプリを特定することに繋がるログを出力するための出力設定に関するオプションを追加することとする。具体的なオプションとしては、例えば、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時にヒープダンプログを取得するための「−ＸＸ：＋ＨｅａｐＤｕｍｐＯｎＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ」がある。また、ローテーションにより多くのＧＣログを残すための「−ＸＸ：＋ＵｓｅｒＧＣＬｏｇＦｉｌｅＲｏｔａｔｉｏｎ」オプションもある。問題特定部３０２は、このようなオプションをつけて起動するように設定を変更し、ＨＤＤ１０４に記憶する。ここでのオプションは、発生した問題に応じて異なる起動オプションが設定されるような構成であってもよい。

Ｓ９０３にて、問題特定部３０２は、変更した起動オプションを適用するためにＪａｖａＶＭを再起動させる。そして、Ｓ５０５にて。問題特定部３０２は、特定アプリを割当候補ＪａｖａＶＭ上で起動させる。また、Ｓ５０６にて、問題特定部３０２は、特定アプリを管理対象アプリに設定する。その後、Ｓ９０４にて、問題特定部３０２は、ＨＤＤ１０４に記憶している問題発生回数を１回増やす。そして、本処理フローを終了する。

なお、図９のＳ９０２にて起動オプションを変更した場合、問題発生回数をカウントした値は初期化してもよい。もしくは、図４のＳ４１２の処理にて問題アプリが特定されたのち、問題発生回数のカウント値を初期化するような構成であってもよい。

以上、本実施形態では、割当候補ＪａｖａＶＭを起動する場合、安全ＪａｖａＶＭとは異なる起動オプションを自動的に追加して起動する。これにより、より詳細なログを自動で出力することが可能となり、早期に問題アプリを特定することが可能となる。

＜その他の実施形態＞
本発明は上述の実施形態の１以上の機能を実現するプログラムをネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１００…情報処理装置、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…ＨＤＤ、１１１…コントローラユニット、２０１…ＯＳ、２０２…ＪａｖａＰＦ管理部、３０１…プロセス制御部、３０２…問題特定部、３０３…アプリ動作管理部、３０４…ＶＭ起動管理部、３０５…資源管理部

Claims (12)

1. １または複数のアプリを動作させるための動作環境が複数、動作可能な情報処理装置であって、
   アプリの動作時における問題の発生を検知する検知手段と、
   動作している動作環境の中から、前記問題が発生した動作環境を特定する第１の特定手段と、
   前記第１の特定手段にて特定された動作環境において、前記問題の発生が検知されるまでに動作していた１または複数のアプリを特定する第２の特定手段と、
   前記第２の特定手段にて特定された１または複数のアプリが、新たな動作環境にて動作するように動作環境の変更を制御する制御手段と
   を有することを特徴とする情報処理装置。
2. 前記情報処理装置にて動作可能な動作環境の最大数を決定する決定手段を更に有し、
   前記制御手段は、前記決定手段にて決定された最大数の複数の動作環境を動作させ、当該複数の動作環境のいずれかを前記第２の特定手段にて特定された１または複数のアプリが動作する前記新たな動作環境とすることを特徴とする請求項１に記載の情報処理装置。
3. 前記決定手段は、アプリが使用する資源量、動作環境を動作させるために要する資源量、および、使用可能な資源量に基づいて、動作可能な動作環境の最大数を決定することを特徴とする請求項２に記載の情報処理装置。
4. 前記決定手段にて用いられる資源の情報は、メモリ、ファイルサイズ、ディスクリプタ数、ソケット数、スレッド数、およびプロセス数の少なくともいずれかであることを特徴とする請求項３に記載の情報処理装置。
5. 前記制御手段は、前記第２の特定手段にて特定された１または複数のアプリ以外のアプリが、１の動作環境にて動作するように動作環境を変更することを特徴とする請求項１乃至４のいずれか一項に記載の情報処理装置。
6. 前記検知手段、前記第１の特定手段、前記第２の特定手段、および前記制御手段による処理が繰り返されることで、前記問題の原因となる１のアプリが１の動作環境にて動作するように動作環境が変更されることを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 前記検知手段による問題の検知の回数が所定の回数を超えたか否かを判定する判定手段と、
   前記判定手段にて前記所定の回数を超えたと判定された場合、前記新たな動作環境においてアプリを動作させた際の出力設定を変更する変更手段と
   を更に有することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
8. 前記出力設定は、アプリの動作に関するログの設定であることを特徴とする請求項７に記載の情報処理装置。
9. 前記情報処理装置は、画像形成装置であることを特徴とする請求項１乃至８のいずれか一項に記載の情報処理装置。
10. 前記動作環境は、Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（ＪａｖａＶＭ）であることを特徴とする請求項１乃至９のいずれか一項に記載の情報処理装置。
11. １または複数のアプリを動作させるための動作環境が複数、動作可能な情報処理装置の制御方法であって、
    アプリの動作時における問題の発生を検知する検知工程と、
    動作している動作環境の中から、前記問題が発生した動作環境を特定する第１の特定工程と、
    前記第１の特定工程にて特定された動作環境において、前記問題の発生が検知されるまでに動作していた１または複数のアプリを特定する第２の特定工程と、
    前記第２の特定工程にて特定された１または複数のアプリが、新たな動作環境にて動作するように動作環境の変更を制御する制御工程と
    を有することを特徴とする情報処理装置の制御方法。
12. １または複数のアプリを動作させるための動作環境が複数、動作可能なコンピューターを、
    アプリの動作時における問題の発生を検知する検知手段、
    動作している動作環境の中から、前記問題が発生した動作環境を特定する第１の特定手段、
    前記第１の特定手段にて特定された動作環境において、前記問題の発生が検知されるまでに動作していた１または複数のアプリを特定する第２の特定手段、
    前記第２の特定手段にて特定された１または複数のアプリが、新たな動作環境にて動作するように動作環境の変更を制御する制御手段
    として機能させるためのプログラム。

Images