(57)【要約】【課題】ユーザ操作を必要とすることなく、メモリ不足が発生した場合に必要なときのみダンプファイルを出力する仕組みを提供する。【解決手段】情報処理装置は、アプリケーションからのメモリ要求に従ってメモリ領域を確保し、確保できない場合には例外を発生させ、例外が発生すると、他のアプリケーションで確保している不要になったメモリ領域を解放し、メモリ領域を再配置するＧＣ処理を実行し、アプリケーションの開発段階における例外の発生であれば、ＧＣ処理を実行した後のメモリの状態を示すヒープダンプファイルの生成を行わず、アプリケーションの開発段階における例外の発生でなければ、ヒープダンプファイルの生成を行う。【選択図】  図５
2016095792.tif 000002
【特許請求の範囲】
【請求項１】
情報処理装置であって、
アプリケーションからのメモリ要求に従ってメモリ領域を確保し、確保できない場合には例外を発生させるメモリ制御手段と、
前記例外が発生すると、他のアプリケーションで確保している不要になったメモリ領域を解放し、メモリ領域を再配置するＧＣ処理を実行する実行手段と、
前記実行手段によってＧＣ処理が実行されると、前記情報処理装置に格納されている情報に基づき、前記アプリケーションの開発段階における前記例外の発生であるか否かを判定する判定手段と、
前記判定手段による判定結果に基づき、前記アプリケーションの開発段階における前記例外の発生であれば、前記実行手段による前記ＧＣ処理を実行した後のメモリの状態を示すヒープダンプファイルの生成を行わず、前記アプリケーションの開発段階における前記例外の発生でなければ、前記ヒープダンプファイルの生成を行う生成手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記情報処理装置に格納されている情報は、該情報処理装置の開発が完了しているか否かを示す第１情報を含み、
前記判定手段は、前記情報処理装置の開発が完了していることを前記第１情報が示す場合は、前記アプリケーションの開発段階における前記例外の発生であると判定し、前記情報処理装置の開発が完了していないことを前記第１情報が示す場合は、前記アプリケーションの開発段階における前記例外の発生でないと判定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記情報処理装置に格納されている情報は、該情報処理装置の開発が完了しているか否かを示す第１情報、及び該情報処理装置にアプリケーションをインストールする際にコード署名認証を行うか否かを示す第２情報を含み、
前記判定手段は、前記情報処理装置の開発が完了していることを前記第１情報が示し、かつ、前記コード署名認証を行わないことを前記第２情報が示す場合は、前記アプリケーションの開発段階における前記例外の発生であると判定し、前記情報処理装置の開発が完了していないことを前記第１情報が示す場合、又は、前記コード署名認証を行うことを前記第２情報が示す場合は、前記アプリケーションの開発段階における前記例外の発生でないと判定することを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記情報処理装置に格納されている情報は、該情報処理装置の開発が完了しているか否かを示す第１情報、及び前記メモリ要求を行ったアプリケーションのライセンスファイルのチェックを行うか否かを示す第３情報を含み、
前記判定手段は、前記情報処理装置の開発が完了していることを前記第１情報が示し、かつ、前記ライセンスファイルのチェックを行わないことを前記第３情報が示す場合は、前記アプリケーションの開発段階における前記例外の発生であると判定し、前記情報処理装置の開発が完了していないことを前記第１情報が示す場合、又は、前記ライセンスファイルのチェックを行うことを前記第３情報が示す場合は、前記アプリケーションの開発段階における前記例外の発生でないと判定することを特徴とする請求項１に記載の情報処理装置。
【請求項５】
前記情報処理装置に格納されている情報は、該情報処理装置の開発が完了しているか否かを示す第１情報、該情報処理装置にアプリケーションをインストールする際にコード署名認証を行うか否かを示す第２情報、及び前記メモリ要求を行ったアプリケーションのライセンスファイルのチェックを行うか否かを示す第３情報を含み、
前記判定手段は、前記情報処理装置の開発が完了していることを前記第１情報が示し、かつ、前記コード署名認証を行わないことを前記第２情報が示し、かつ、前記ライセンスファイルのチェックを行わないことを前記第３情報が示す場合は、前記アプリケーションの開発段階における前記例外の発生であると判定し、前記情報処理装置の開発が完了していないことを前記第１情報が示す場合、前記コード署名認証を行うことを前記第２情報が示す場合、又は、前記ライセンスファイルのチェックを行うことを前記第３情報が示す場合は、前記アプリケーションの開発段階における前記例外の発生でないと判定することを特徴とする請求項１に記載の情報処理装置。
【請求項６】
前記生成手段は、前記アプリケーションの開発段階における前記例外の発生でないと前記判定手段によって判定された場合に、当該例外の発生が所定期間内における初回の発生であれば、前記ヒープダンプファイルの生成を行うことを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。
【請求項７】
前記生成手段は、前記ヒープダンプファイルを生成すると、前記例外の発生が所定期間内における初回の発生であるか否かを示す第４情報を、初回の発生でないことを示す情報に変更することを特徴とする請求項６に記載の情報処理装置。
【請求項８】
前記生成手段は、前記例外の初回の発生から前記所定期間が経過すると、前記第４情報を、初回の発生であることを示す情報に変更することを特徴とする請求項７に記載の情報処理装置。
【請求項９】
前記生成手段は、前記アプリケーションの開発段階における前記例外の発生でないと前記判定手段によって判定された場合に、前記情報処理装置がシミュレータでなければ、前記ヒープダンプファイルの生成を行うことを特徴とする請求項１乃至８の何れか１項に記載の情報処理装置。
【請求項１０】
前記第１情報は、前記情報処理装置の工場出荷時に、該情報処理装置の開発が完了していないことを示す情報から、該情報処理装置の開発が完了していることを示す情報に変更されることを特徴とする請求項２乃至９の何れか１項に記載の情報処理装置。
【請求項１１】
前記第２情報は、前記アプリケーションの作成者によって設定されることを特徴とする請求項３又は５に記載の情報処理装置。
【請求項１２】
前記第３情報は、前記アプリケーションの作成者によって設定されることを特徴とする請求項４又は５に記載の情報処理装置。
【請求項１３】
情報処理装置の制御方法であって、
メモリ制御手段が、アプリケーションからのメモリ要求に従ってメモリ領域を確保し、確保できない場合には例外を発生させるメモリ制御工程と、
実行手段が、前記例外が発生すると、他のアプリケーションで確保している不要になったメモリ領域を解放し、メモリ領域を再配置するＧＣ処理を実行する実行工程と、
判定手段が、前記実行工程でＧＣ処理が実行されると、前記情報処理装置に格納されている情報に基づき、前記アプリケーションの開発段階における前記例外の発生であるか否かを判定する判定工程と、
生成手段が、前記判定工程による判定結果に基づき、前記アプリケーションの開発段階における前記例外の発生であれば、前記実行工程による前記ＧＣ処理を実行した後のメモリの状態を示すヒープダンプファイルの生成を行わず、前記アプリケーションの開発段階における前記例外の発生でなければ、前記ヒープダンプファイルの生成を行う生成工程と
を実行することを特徴とする情報処理装置の制御方法。
【請求項１４】
請求項１３に記載の情報処理装置の制御方法における各工程をコンピュータに実行させるための該コンピュータで読み取り可能なプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ログファイル（ヒープダンプファイル）の生成を制御する情報処理装置、その制御方法、及びプログラムに関するものである。
【背景技術】
【０００２】
従来から、画像形成装置（ＭＦＰ）上で動作するアプリケーション（以下、アプリと称する。）の実行環境としてＪａｖａ（登録商標）が広く知られている。この実行環境では、Ｊａｖａ言語で記述されたアプリ（以下、Ｊａｖａアプリと称する。）が、Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ（ＪａｖａＶＭ）上で動作する。Ｊａｖａアプリはメモリを利用する場合、ＪａｖａＶＭにメモリ要求を行う。ＪａｖａＶＭは、ＭＦＰのメモリ領域からＪａｖａアプリが利用可能なメモリ領域（Ｊａｖａヒープ領域）として固定の領域をあらかじめ確保しており、Ｊａｖａアプリからのメモリ要求を受信すると、Ｊａｖａヒープ領域に空きがあるかを確認する。そして空きがある場合、ＪａｖａＶＭはＪａｖａアプリからの要求に応じたメモリ領域をＪａｖａアプリが利用可能にする。一方、Ｊａｖａヒープ領域に空きがない場合は、ＪａｖａＶＭはＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒというＥｘｃｅｐｔｉｏｎ（例外）を生成し、Ｊａｖａアプリにこの例外を通知する。このＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時は、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの原因を特定するために、ヒープダンプファイルというログファイルを生成するのが一般的である。このヒープダンプファイルは、Ｊａｖａヒープ領域内の状態を表したファイルであり、このファイルを解析することでＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの原因が特定できる。ただし、このヒープダンプファイルを生成するためには、Ｊａｖａヒープ領域の利用メモリ状況を正確に知るために、ヒープダンプファイル生成前に、Ｇａｒｂａｇｅ  Ｃｏｌｌｅｃｔｉｏｎ（ＧＣ）処理を行う必要がある。このＧＣ処理はＪａｖａＶＭが実行する処理であり、実行中は全てのＪａｖａアプリに関係する動作が停止する。特に、ヒープ領域中のＮｅｗ領域だけではなくＯｌｄ領域とＰｅｒｍａｎｅｎｔ領域に存在するオブジェクトも削除するＦｕｌｌＧＣの場合、停止時間が長くなる。
【０００３】
そのため、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時に毎回ヒープダンプファイルを生成すると、頻繁にシステム全体が停止してしまうという課題がある。特許文献１には、特定の種類の例外が発生したときのみログファイルを生成する技術が提案されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−１８６３７８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記従来技術には以下に記載する問題がある。上記従来技術では、例外の種類に応じてヒープダンプファイルの生成の有無を切り替えることが可能となる。しかし、上記従来技術では、例外の種類により生成の有無を切り替えるため、同じ種類の例外が短時間に発生したときに、ヒープダンプファイルの生成の有無を切り替えることができず、重複してヒープダンプファイルを生成してしまうという課題がある。ヒープダンプファイルの生成の有無を切り替える必要がある状況として、例えば次のような状況がある。
【０００６】
ＭＦＰ上で動作するＪａｖａアプリを作成した場合、アプリ作成者は、このＪａｖａアプリが使用する最大メモリ使用量を宣言する必要がある。なお、最大メモリ使用量は、Ｊａｖａアプリに同梱するＭＡＮＩＦＥＳＴファイルというアプリの属性を記載するファイルに記載される。この最大メモリ使用量は、ＭＦＰ上で動作するＪａｖａアプリの合計メモリ量が、ＭＦＰで利用可能なＪａｖａアプリのメモリ量を超えないように、Ｊａｖａアプリのインストールを制限するために利用する。
【０００７】
最大使用メモリ量を調べるために、アプリ作成者は最大メモリ使用量測定ツール（以下、測定ツールと称する。）というＳｅｒｖｌｅｔタイプのＪａｖａアプリをＭＦＰ上で動作させる。この測定ツールは、アプリ作成者が設定する推定メモリ量以外のメモリ領域を利用し、空き容量を推定メモリ量だけに変更するツールである。この測定ツールを用いてアプリ作成者は作成したＪａｖａアプリのＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生しない最大の推定メモリ量を決定する。しかし、当該決定においては、何度もＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを発生させる必要がある。そのため、メモリリーク等の障害によるＯｕｔＯｆＭｅｍｏｒｙ発生時はヒープダンプファイルを生成したいが、最大使用メモリ量を決定するために故意に発生させたＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時はファイルの生成を行いたくないという状況がある。上記従来技術では、このような状況に対応することができない。
【０００８】
本発明は、上述の問題に鑑みて成されたものであり、ユーザ操作を必要とすることなく、メモリ不足が発生した場合に必要なときのみダンプファイルを出力する仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、情報処理装置であって、アプリケーションからのメモリ要求に従ってメモリ領域を確保し、確保できない場合には例外を発生させるメモリ制御手段と、前記例外が発生すると、他のアプリケーションで確保している不要になったメモリ領域を解放し、メモリ領域を再配置するＧＣ処理を実行する実行手段と、前記実行手段によってＧＣ処理が実行されると、前記情報処理装置に格納されている情報に基づき、前記アプリケーションの開発段階における前記例外の発生であるか否かを判定する判定手段と、前記判定手段による判定結果に基づき、前記アプリケーションの開発段階における前記例外の発生であれば、前記実行手段による前記ＧＣ処理を実行した後のメモリの状態を示すヒープダンプファイルの生成を行わず、前記アプリケーションの開発段階における前記例外の発生でなければ、前記ヒープダンプファイルの生成を行う生成手段とを備えることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、ユーザ操作を必要とすることなく、メモリ不足が発生した場合に必要なときのみダンプファイルを出力することができる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施形態に係る画像形成装置１００のコントローラユニット１２０を表すブロック図。
【図２】第１の実施形態に係るコントローラユニット１２０のソフトウェア構成を表すブロック図。
【図３】第１の実施形態に係るＪａｖａＶＭ２０２とＯＳ２０３のモジュール構成を表す図。
【図４】第１の実施形態に係る画像形成装置１００で生成するヒープダンプファイルの一具体例を示す図。
【図５】第１の実施形態に係るＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時の処理を表すフローチャート。
【図６】第１の実施形態に係るＧＣの処理を表すフローチャート図である。
【図７】第１の実施形態に係る開発用Ｊａｖａアプリと製品用Ｊａｖａアプリの構成を表す図。
【図８】Ｊａｖａアプリの最大メモリ使用量を測定する流れを表す図。
【図９】第２の実施形態に係るＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時の処理を表すフローチャート。
【発明を実施するための形態】
【００１２】
以下、添付図面を参照して本発明の実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００１３】
＜第１の実施形態＞
＜画像形成装置の構成＞
以下では、図１乃至図８を参照して、本発明の第１の実施形態について説明する。まず、図１を参照して、本実施形態に係る画像形成装置１００のコントローラユニットについて説明する。ここでは、本発明を適用することができる情報処理装置の一例として画像形成装置１００について説明する。
【００１４】
画像形成装置１００は、コントローラユニット１２０、操作部１０６、スキャナ１１６、及びプリンタ１１８を備える。コントローラユニット１２０は、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ＨＤＤ１０４、操作部Ｉ／Ｆ１０５、ネットワーク部１０７、イメージバスＩ／Ｆ１０９、電源管理部１１０、ＲＩＰ１１３、デバイスＩ／Ｆ１１４、及び画像処理部１１９を備える。
【００１５】
コントローラユニット１２０は、画像情報やデバイス情報の入出力を行うだけではなく、装置全体の制御や、ネットワークを介して外部から提供されるデータをプリント出力する制御を行う。また、ネットワークを介した電子メール送信機能を含む通信機能における制御も行う。
【００１６】
ＣＰＵ１０１は、ＲＯＭ１０３に格納されているブートプログラムに基づきシステムを起動し、このシステム上でＨＤＤ（ハードディスクドライブ）１０４に格納されている制御プログラムを読み出してＲＡＭ１０２をワークエリアとして各種処理を実行する。この制御プログラムにより、Ｊａｖａプログラムなどの制御を実行することが可能である。ＨＤＤ１０４には、上記各種制御プログラムが格納されるとともに、画像データや後述するネットワーク部１０７が有する全ての通信手法に関する情報を格納する。
【００１７】
ＣＰＵ１０１には、ＲＡＭ１０２、ＲＯＭ１０３、ＨＤＤ１０４がシステムバス１１１を介して接続されている。さらに、操作部Ｉ／Ｆ１０５、ネットワーク部１０７、イメージバスＩ／Ｆ１０９、及び電源管理部１１０がシステムバス１１１を介して接続されている。
【００１８】
操作部Ｉ／Ｆ１０５は、操作部１０６とコントローラユニット１２０との間のインターフェースであり、操作部１０６に表示する画像データの操作部１０６への転送、操作部１０６における操作入力により発生した信号のＣＰＵ１０１への転送などを行う。操作部１０６は、画像処理に関する各機能における現在の設定状態、各機能に関する設定情報を入力するための情報入力画面などを表示するための表示部、ユーザが各機能に対する設定情報を入力するキーなどを含む入力部を有する。
【００１９】
電源管理部１１０は、画像形成装置１００の電源ＯＦＦと電源ＯＮの管理を行う。なお、電源ＯＮを検知した場合、上述のように、ＣＰＵ１０１は、ＲＯＭ１０３のブートプログラムに基づきシステムを起動し、このシステム上でＨＤＤ１０４に格納されている制御プログラムを実行する。
【００２０】
ネットワーク部１０７は、ＬＡＮ１０８に接続され、ＬＡＮ１０８を介した情報の入出力を行う。ＬＡＮ回線にｗｅｂサーバや外部装置４００が接続されている場合は、そのサーバからＬＡＮ１０８を介して情報を取得することが可能である。また、ＬＡＮ回線内のプロキシサーバなどを介して、インターネットに接続し、インターネット上のｗｅｂサーバからｗｅｂコンテンツを取得することも可能である。
【００２１】
イメージバスＩ／Ｆ１０９は、システムバス１１１と、画像バス１１２とを接続し、データ構造を変換するバスブリッジである。画像バス１１２は、画像データを高速で転送可能なＰＣＩバス又はＩＥＥＥ１３９４規定に従うバスから構成される。画像バス１１２には、ＲＩＰ（ラスタイメージプロセッサ）１１３、デバイスＩ／Ｆ１１４及び画像処理部１１９が接続されている。
【００２２】
ＲＩＰ１１３は、ＰＤＬコードをビットマップイメージに展開する。デバイスＩ／Ｆ１１４は、画像入出力デバイスであるスキャナ１１６やプリンタ１１８とコントローラユニット１２０とを接続し、画像データの同期系／非同期系の変換を行う。ここでは、デバイスＩ／Ｆ１１４とスキャナ１１６とがケーブル１１５を介して、デバイスＩ／Ｆ１１４とプリンタ１１８とがケーブル１１７を介してそれぞれ接続されている。
【００２３】
画像処理部１１９は、多値画像データに対してＪＰＥＧ、二値画像データに対してＪＢＩＧ、ＭＭＲ、ＭＨなどの圧縮伸張処理を行う。また、入力画像データや出力画面に対して、プリンタの補正や解像度変換などの補正、加工、編集を行う。このように、コントローラユニット１２０のＣＰＵ１０１は、各制御プログラムに基づき、システムバス１１１に接続される各種デバイスとのアクセスを総括的に制御するととともに、デバイスＩ／Ｆ１１４を介してスキャナ１１６から画像情報を読み込む。また、読み込んだ画像情報に対して所定の処理を施した後に当該画像情報をデバイスＩ／Ｆ１１４を介してプリンタ１１８に出力するなどの制御を行う。さらに、ネットワーク部１０７を通じて取得したＨＴＭＬデータや画像データの解析・変換処理を行い、ＨＤＤ１０４へ保存、又は操作部１０６での表示制御を行う。
【００２４】
＜ソフトウェア構成＞
次に、図２を参照して、画像形成装置１００のＣＰＵ１０１やＨＤＤ１０４などの各ハードウェア上で動作するソフトウェアのモジュール構成について説明する。なお、これらの各モジュールにおける処理は、ＣＰＵ１０１の命令により、ＲＯＭ１０３やＨＤＤ１０４に格納されているプログラムを読み出し、ＲＡＭ１０２をワークエリアとして処理を実行することで実現される。また、各処理を実行することで生成される全ての情報は、ＲＡＭ１０２又はＨＤＤ１０４に格納する。なお、このような各モジュールにおける処理は、以降でも同様であるため、以降では記載を省略する。
【００２５】
ＯＳ２０１は、メモリ管理、入出力管理、及びプロセス管理を行うモジュールであり、一般的なＯＳと同様の処理を行う。ＪａｖａＶＭ２０２は、ＲＯＭ１０３又はＨＤＤ１０４に格納されているＪａｖａバイトコードを実行することでＪａｖａプログラムを動作させる仮想マシンである。
【００２６】
アプリプラットフォーム２０３は、単一のＪａｖａＶＭ２０２上で少なくとも１つ以上のＪａｖａアプリケーション（以下、Ｊａｖａアプリ又はアプリと称する。）の起動、停止、インストール、アンインストールといったアプリのライフサイクルの管理・実行を行うモジュールである。また、アプリプラットフォーム２０３は、アプリＡ２０４やアプリＢ２０５で共通に利用するライブラリやサービスを有する。
【００２７】
アプリＡ２０４とアプリＢ２０５は、アプリプラットフォーム２０３上で動作するＪａｖａプログラムのバイトコードであり、アプリプラットフォーム２０３が有するライブラリやサービスを利用して動作する。また、アプリＡ２０４とアプリＢ２０５は、個別に画像形成装置１００にインストールして、アプリプラットフォーム２０３で起動することが可能である。アプリＣ２０６は、Ｊａｖａアプリ以外のアプリプログラム、例えば、Ｃ言語のアプリであり、ＯＳ２０１上で動作する。
【００２８】
＜ＪａｖａＶＭ２０２とプラットフォーム２０３の処理＞
次に、図３を参照して、ＪａｖａＶＭ２０２とアプリプラットフォーム２０３の詳細な処理について説明する。ＪａｖａＶＭ２０２は、バイトコード実行部３０１、クラスローダ管理部３０２、ＧＣ実行部３０３、メモリ制御部３０４、ヒープダンプファイル情報生成部３０５、及びＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生部３０６を備える。アプリプラットフォーム２０３は、アプリ管理部３０７、ヒープダンプファイル生成判定部３０８、ヒープダンプファイル生成実行部３０９を備える。
【００２９】
アプリ管理部３０７は、Ｊａｖａアプリのインストール、起動、停止、アンインストールといったアプリのライフサイクルの管理・実行を行うためのものであり、一般的なＯＳＧｉと同じ処理を行う。バイトコード実行部３０１は、アプリ管理部３０７で起動したアプリのバイトコードを解釈し、アプリの処理を実行する。また、バイトコード実行部３０１は、アプリのオブジェクト生成などの処理でＪａｖａヒープメモリを利用する場合は、メモリ制御部３０４にメモリ利用要求を送信する。
【００３０】
クラスローダ管理部３０２は、クラスローダの生成と管理を行うと共に、Ｊａｖａのクラスを動的にロードし、バイトコード実行部３０１で利用可能にする。また、クラスローダ管理部３０２は、アプリ管理部３０７で起動したアプリの利用するライブラリやサービスのクラスがロードされていない場合、このクラスをロードし、利用可能にする。
【００３１】
メモリ制御部３０４は、メモリ利用要求を受信すると、Ｊａｖａヒープメモリ領域（以下、メモリ領域と称する。）の利用状況を調べる。そしてメモリ制御部３０４は、空き領域があればこのメモリ領域を返し、空き領域がなければＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生部３０６にＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を要求する。また、メモリ制御部３０４は、Ｊａｖａアプリのどのオブジェクトがどれくらいのメモリを利用しているのかを示す情報をＨＤＤ１０４に格納する。また、メモリ制御部３０４は、ＧＣ実行部３０３にＧＣ（Ｇａｒｂａｇｅ  Ｃｏｌｌｅｃｔｉｏｎ）処理の実行要求を行う。ＧＣ処理の詳細については図６を用いて後述する。さらに、メモリ制御部３０４は、ヒープダンプファイル生成判定部３０８にヒープダンプファイルの生成判定要求を行い、ヒープダンプファイル情報生成部３０５にヒープダンプファイル情報生成要求を行う。ＧＣ実行部３０３は、メモリ領域を利用しているＪａｖａオブジェクトのうち、使用されなくなったものを削除するためにＧＣ処理を行う。ＧＣ処理は、メモリ制御部３０４からのＧＣ実行要求又は一定以上のメモリ領域が利用された場合に実行される。
【００３２】
ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生部３０６は、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの例外を発生させ、メモリ要求元アプリにこの例外を通知する。例外の生成とアプリへの通知の詳細処理は、一般的な仕組みと同じであるため記載は省略する。ヒープダンプファイル生成判定部３０８は、ヒープダンプファイルを生成するかどうかを後述の条件により判定する。ヒープダンプファイル情報生成部３０５は、ＨＤＤ１０４からメモリ領域の状態を表す情報を取得する。ヒープダンプファイル生成実行部３０９は、ヒープダンプファイル情報生成部３０５で取得した情報を元に、ヒープダンプファイルを生成する。
【００３３】
＜ＧＣ処理＞
次に、図６を参照して、ＧＣ実行部３０３によるＧＣ処理について説明する。以下で説明する処理は、ＣＰＵ１０１の命令により、ＲＯＭ１０３やＨＤＤ１０４に格納されているプログラムを読み出し、ＲＡＭ１０２をワークエリアとして処理を実行することで実現される。ここで、ＧＣ処理とは、Ｊａｖａアプリケーション等のプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する処理を示す。
【００３４】
まずＳ２０１で、ＧＣ実行部３０３は、他の処理を停止し、一般的な“ｓｔｏｐ  ｔｈｅ  ｗｏｒｌｄ”といわれる画像形成装置１００のシステム全体が停止する状態に制御する。続いてＳ２０２で、ＧＣ実行部３０３は、メモリ領域内のＧＣ対象であるオブジェクトの中で参照されていない（使用されていない）オブジェクトを検索する。この結果Ｓ２０３で、ＧＣ実行部３０３は、参照されていないオブジェクトが存在すれば、このオブジェクトを全て削除する。
【００３５】
次にＳ２０４で、ＧＣ実行部３０３は、メモリ領域の断片化（フラグメンテーション）を防ぐために、メモリ領域の再配置を行う。続いてＳ２０５で、ＧＣ実行部３０３は、メモリ領域の再配置後のメモリ領域の状態（どのオブジェクトがどれくらいのメモリを利用しているかの状態）をＨＤＤ１０４に格納する。なお、このＳ２０５でＨＤＤ１０４に格納した情報が、ヒープダンプファイルに記載する内容となる。そしてＳ２０６で、ＧＣ実行部３０３は、Ｓ２０１で停止した処理の実行を再開し、システム全体を再開する。
【００３６】
＜最大使用量＞
ここで、図８を参照して、測定ツールを用いたアプリ作成者による作成したＪａｖａアプリの最大使用メモリ量を調べる手法の一例について説明する。
【００３７】
まず、作成したＪａｖａアプリと測定ツールをＭＦＰ等の画像形成装置にインストールする。そして、測定ツールで推定メモリ量を設定する（８０１から８０２になる）。この後に、開発用のＪａｖａアプリを動作させて、メモリ不足によって発生するＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生するかどうかを確認する（８０３）。ここでもし、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生すれば、開発用のＪａｖａアプリは推定メモリ量よりも大きいサイズのメモリ量を使用していることが分かる（８０４）。そのためアプリ作成者は、設定した推定メモリ量よりもさらに小さい値の推定メモリ量を測定ツールに設定し、再度開発用のＪａｖａアプリを動作させる。
【００３８】
一方、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生しなかった場合は、開発用のＪａｖａアプリは推定メモリ量よりも小さいサイズのメモリ量を使用していることが分かる（８０５）。そのためアプリ作成者は、設定した推定メモリ量よりもさらに大きい値の推定メモリ量を測定ツールに設定し、再度開発用のＪａｖａアプリを動作させる。アプリ作成者は、これらの操作を繰り返し行い、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生しない最大の推定メモリ量を決定し、この値をＭＡＮＩＦＥＳＴファイルに最大使用メモリ量として記載する。
【００３９】
したがって、上記測定ツールを用いた最大使用メモリ量の調整段階において、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生するごとにヒープダンプファイルを生成して出力することは効率が著しく低下してしまう。そこで、本実施形態では、ヒープダンプファイルの生成の有無を好適に切り替える。なお、本実施形態の手法を用いれば、操作者等の入力を必要とすることなく、ヒープダンプファイルの生成の有無を切り替えることができる。
【００４０】
＜切替処理＞
次に、図５を参照して、ＪａｖａＶＭ２０２とアプリプラットフォーム２０３の各モジュールにより、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生した場合に、状況に応じてヒープダンプファイルの生成有無を切り替える切替処理について説明する。以下で説明する処理は、ＣＰＵ１０１の命令により、ＲＯＭ１０３やＨＤＤ１０４に格納されているプログラムを読み出し、ＲＡＭ１０２をワークエリアとして処理を実行することで実現される。
【００４１】
メモリ制御部３０４は、バイトコード実行部３０１によるＪａｖａアプリのメモリ要求に対して、要求のメモリを確保できない場合、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生部３０６にＯｕｔＯｆＭｅｍｏｒｙ発生要求を通知する。ＯｕｔＯｆＭｅｍｏｒｙ発生要求を受信すると、Ｓ１０１で、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生部３０６は、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの例外を発生させる。メモリ制御部３０４は、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生部３０６によるＯｕｔＯｆＭｅｍｏｒｙの発生処理が完了すると、ＧＣ実行部３０３にＧＣ処理の実行要求を送信する。ＧＣ処理の実行要求を受信すると、Ｓ１０２で、ＧＣ実行部３０３は、図６を用いて説明したＧＣ処理を実行する。その後Ｓ１０３で、メモリ制御部３０４は、ヒープダンプファイルの生成判定要求を、ヒープダンプファイル生成判定部３０８に送信する。
【００４２】
ヒープダンプファイルの生成判定要求を受信すると、Ｓ１０４乃至Ｓ１０６で、ヒープダンプファイル生成判定部３０８は、ヒープダンプファイルを生成するか否かを以下の条件から判定する。具体的には、Ｓ１０４乃至Ｓ１０６の判定において、Ｊａｖａアプリの開発段階におけるＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生であるか否かを確認して、ヒープダンプファイルを生成するか否かを決定している。なお、Ｊａｖａアプリの開発段階ということは、通常は、画像形成装置１００自体の開発は完了している。ここでは、一例として、３つの条件を用いる場合について説明する。
【００４３】
１つ目の条件は、画像形成装置１００が製品の開発が完了しているか否かの判定である（Ｓ１０４）。製品の開発が完了しているか否かの情報（第１情報）は、ＲＯＭ１０３に格納しているフェーズ情報を用いて判定することができる。当該フェーズ情報は、デフォルトは製品開発中であり、工場出荷時（画像形成装置１００の製品販売時）にのみ製品開発中から開発完了に変更される。そのため、フェーズ情報は、ユーザが変更することができない。
【００４４】
具体例を説明する。アプリ作成者が、作成した開発用のＪａｖａアプリの最大メモリ使用量を、測定ツールを用いて測定を行うのは、工場出荷後の画像形成装置１００を用いて行う。そのため、測定ツールによりＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生した場合、Ｓ１０４の判定はＹＥＳとなる。一方、画像形成装置１００の製品開発中にメモリリーク等でＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生した場合、Ｓ１０４の判定はＮＯとなる。
【００４５】
２つ目の条件は、Ｊａｖａアプリのインストール時にコード署名認証を行うか否かの判定である（Ｓ１０５）。このコード署名認証を行うか否かは、ＨＤＤ１０４に格納されているコード署名認証フラグを参照して判定する。このコード署名認証フラグ（第２情報）は、認証ありと認証なしの設定値があり、アプリ作成者が自由に変更することが可能である。
【００４６】
ここで、図７を参照して、コード署名認証フラグの利用方法について説明する。Ｊａｖａアプリは開発用と製品用の２種類あり、図７に示すように構成が異なる。製品用のＪａｖａアプリを作成する場合、７０１に示すように、一般的なコードサイン証明書を用いたアプリ配布と同じ手順で作成する。具体的には、作成した３つのファイル（ＪａｖａプログラムとＭＡＮＩＦＥＳＴファイルと製品用のライセンスファイル）に対するハッシュ値を取り、このハッシュ値を暗号化する。また、サーバ（認証局）からコード署名証明書を取得する。そして、暗号化したハッシュ値と３つのファイルとコード署名証明書を１つのｊａｒファイルとしてまとめて、Ｊａｖａアプリとする。
【００４７】
一方、開発用のＪａｖａアプリを作成する場合、７０２に示すように、作成した３つのファイル（ＪａｖａプログラムとＭＡＮＩＦＥＳＴファイルと開発用のライセンスファイル）を１つのｊａｒファイルとしてまとめ、開発用Ｊａｖａアプリを作成する。この開発用Ｊａｖａアプリは、コード署名認証を行っていないため、画像形成装置１００のＨＤＤ１０４に格納されているコード署名認証フラグが認証ありの場合、画像形成装置１００にインストールすることができない。具体例を説明する。アプリ作成者が、作成した開発用のＪａｖａアプリの最大メモリ使用量を、測定ツールを用いて測定を行う場合、開発用のＪａｖａアプリを画像形成装置１００にインストールするため、コード署名認証フラグを認証なしにしている。そのため、測定ツールによりＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生した場合、Ｓ１０５の判定はＮＯとなる。一方、ＭＦＰの工場出荷後は市販のＪａｖａアプリしかインストールできなくするため、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時のＳ１０５の判定はＹＥＳとなる。
【００４８】
３つ目の条件は、Ｊａｖａアプリに含まれるライセンスファイルのチェックを行うか否かの判定である（Ｓ１０６）。このライセンスファイルのチェックを行うか否かは、ＨＤＤ１０４に格納されているライセンスチェックフラグを参照して判定する。このライセンスチェックフラグ（第３情報）は、チェックありとチェックなしの設定値があり、アプリ作成者が自由に変更することが可能である。アプリ作成者が図７のようにして作成したＪａｖａアプリには、ライセンスファイルとして製品用ライセンス又は開発用ライセンスの情報を含む。この開発用ライセンスの情報を含むＪａｖａアプリは、画像形成装置１００のＨＤＤ１０４に格納されているライセンスチェックフラグがチェックありの場合は、ＭＦＰにインストールすることができない。
【００４９】
具体例を説明する。アプリ作成者が、作成した開発用のＪａｖａアプリの最大メモリ使用量を、測定ツールを用いて測定を行う場合、開発用のＪａｖａアプリを画像形成装置１００にインストールするため、ライセンスチェックフラグをチェックなしにしている。そのため、測定ツールによりＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生した場合、Ｓ１０６の判定はＮＯとなる。一方、画像形成装置１００の工場出荷後は市販のＪａｖａアプリをインストールした場合、ライセンスチェックを必ず行うようにするため、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時のＳ１０６の判定はＹＥＳとなる。
【００５０】
ヒープダンプファイル生成判定部３０８は、上記の３つの判定結果においてＳ１０４がＹＥＳで、かつ、Ｓ１０５及びＳ１０６がＮＯの場合のみはＳ１０７に進み、メモリ制御部３０４にヒープダンプファイルの生成なしという判定結果を送信し、Ｓ１０９に進む。一方、ヒープダンプファイル生成判定部３０８は、上記判定結果以外の場合はＳ１０８に進み、メモリ制御部３０４にヒープダンプファイルの生成ありという判定結果を送信し、Ｓ１０９に進む。
【００５１】
判定結果を受信すると、Ｓ１０９で、メモリ制御部３０４は、この結果がヒープダンプファイルの生成ありを示すか否かを判定する。この判定結果がヒープダンプファイルの生成なしの場合は、ヒープダンプファイルを出力することなく終了する。一方、この判定結果がヒープダンプファイルの生成ありの場合はＳ１１０に進み、メモリ制御部３０４は、ヒープダンプファイル情報生成部３０５にヒープダンプファイル情報の生成要求を送信する。これを受信したヒープダンプファイル情報生成部３０５は、現在のヒープメモリ状況の情報を取得する。続いて、Ｓ１１１で、ヒープダンプファイル情報生成部３０５は、取得した内容をヒープダンプファイル生成実行部３０９に送信する。これを受信したヒープダンプファイル生成実行部３０９は、Ｓ１１２で、受信した内容のヒープダンプファイルを生成する。これにより、図４のようなヒープダンプファイルが生成される。なお、図４のヒープダンプファイルでは、１行ごとにオブジェクトＩＤ、オブジェクトを生成したクラス、オブジェクトサイズ、生成したオブジェクトへの参照を表示している。
【００５２】
以上説明したように、本実施形態に係る情報処理装置（画像形成装置１００）は、Ｊａｖａアプリからのメモリ要求に従ってメモリ領域を確保し、確保できない場合には例外を発生させる。また、例外が発生すると、他のアプリケーションで確保している不要になったメモリ領域を解放しメモリ領域を再配置するＧＣ処理を実行する。さらに、アプリケーションの開発段階における例外の発生であれば、ＧＣ処理を実行した後のメモリの状態を示すヒープダンプファイルの生成を行わず、アプリケーションの開発段階における例外の発生でなければ、ヒープダンプファイルの生成を行う。このように、同じＯｕｔＯｆＭｅｍｏｒｙが発生した場合であっても３つの条件の判定結果によってヒープダンプファイルの生成有無を切り替えることができる。本実施形態によれば、３つの条件が所定の判定結果の場合（Ｓ１０４がＹＥＳで、かつ、Ｓ１０５及びＳ１０６がＮＯの場合）は、アプリ作成者が測定ツールを用いてアプリの最大使用メモリ量を調べる場合であると判定し、ヒープダンプファイルを生成しない。ヒープダンプファイルを生成しない場合、ヒープダンプファイル生成前に行うＧＣ処理によりシステム全体が停止することがないため、ユーザ（アプリ作成者）の操作性が低下することを防ぐことができる。また、ヒープダンプファイルを生成しない場合、画像形成装置１００のヒープダンプファイル生成に画像形成装置１００のリソース（ＨＤＤやメモリ等）を使わないため、システム負荷を減らすことができる。なお、上記３つの条件は、ヒープダンプファイルの生成有無そのものを意味する条件ではない。そのためユーザ（アプリ開発者）は、測定ツールをインストールするための設定を行うだけであり、生成有無のスイッチを意識して切り替える必要がない。また、３つの条件の中に製品開発中かどうかの判定条件がある。これにより、ＭＦＰの製品開発中に他の２つの条件に一致する状況を作ったとしても、ヒープダンプファイルの生成を行うことができ、Ｊａｖａアプリのメモリリークなどの障害調査も効率的に行うことができる。
【００５３】
＜変形例＞
また、本発明は上記実施形態に限らず様々な変形が可能である。上記実施形態では、ヒープダンプファイルの生成有無を３つの条件（Ｓ１０４〜１０６）を用いて判定し、Ｓ１０４がＹＥＳで、かつ、Ｓ１０５及びＳ１０６がＮＯの場合にヒープダンプファイル生成を行わないこととした。しかし、コード署名認証を行うかどうかの判定（Ｓ１０５）とライセンスファイルのチェックを行うかどうかの判定（Ｓ１０６）は、測定ツールを使う場合に両方とも条件に当てはまる設定に変更することもできる。そのため、Ｓ１０５とＳ１０６の条件は、どちらか一方の条件による判定でもよい。この場合、Ｓ１０４がＹＥＳで、かつ、Ｓ１０５がＮＯの場合、又は、Ｓ１０４がＹＥＳで、かつ、Ｓ１０６がＮＯの場合に、ヒープダンプファイルの生成を行わないこととしてもよい。また、上記３つの条件のうち、少なくとも１つの条件を用いて当該判定を行ってもよい。
【００５４】
＜第２の実施形態＞
以下では、本発明の第２の実施形態について説明する。上記第１の実施形態では、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生したときにヒープダンプファイルを生成するか否かを３つの条件を用いて判定し、所定の判定結果とならない場合はヒープダンプファイルを生成することとした。しかし、この３つの条件だけではなく、別の条件を追加してもよい。
【００５５】
図９を参照して、別の条件を追加する場合の切替処理について説明する。なお、基本的な処理や制御は第１の実施形態と同じであるため、第１の実施形態と異なる点のみを説明する。以下で説明する処理は、ＣＰＵ１０１の命令により、ＲＯＭ１０３やＨＤＤ１０４に格納されているプログラムを読み出し、ＲＡＭ１０２をワークエリアとして処理を実行することで実現される。
【００５６】
上記第１の実施形態では、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生したときにヒープダンプファイルを生成するかどうかの３つの条件で判定し、所定の判定結果とならない場合はヒープダンプファイルを生成することとした（Ｓ１０８）。しかし、画像形成装置１００で動作するＪａｖａアプリは、同じＪａｖａメモリ領域を使っているため、あるＪａｖａアプリでＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生すると、別のＪａｖａアプリでもＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生する可能性が高い。この場合、所定の期間内において、同じ原因で何度もヒープダンプファイルが生成されてしまうという問題がある。
【００５７】
そこで、本実施形態によれば、図９に示すように、Ｓ１０８の処理の前に「所定期間内における初回のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒかどうか」をヒープダンプファイル生成判定部３０８で判定するＳ３０１の処理を追加する。そして、この判定結果が初回のＯｕｔＯｆＭｅｍｏｒＥｒｒｏｒでなければ、ヒープダンプファイルを生成なしと判定してＳ１０７に進み、判定結果が初回の場合はヒープダンプファイルを生成することとしてＳ１０８に進む。なお、初回のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒかどうかの情報（第４情報）はＨＤＤ１０４に保持しておき、ヒープダンプファイル生成実行部３０９がＳ１１２によるヒープダンプファイルを生成後に、初回ではないという情報に更新することにより実現できる。また、所定期間が経過すると、初回であるという情報に戻すことが望ましい。これにより、初回のＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時以外は、所定期間において、ヒープダンプファイルの生成を行わないように制御することができる。なお、上記所定期間については、画像形成装置１００に予め設定されてもよいし、操作者によって設定されてもよい。当該設定情報については、上記第４情報と関連付けてＨＤＤ１０４に保持される。
【００５８】
また、上記第１の実施形態では、画像形成装置１００が製品開発中か否かの判定を行い（Ｓ１０４）、開発中でない場合、ヒープダンプファイルを生成することと判定した（Ｓ１０８）。しかし、画像形成装置１００の製品開発が完了する前に、製品のシミュレータを用いて、作成したＪａｖａアプリの最大使用メモリ量を調べたいこともある。この場合、Ｓ１０４の判定が常にＮＯとなるため、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生時に毎回ヒープダンプファイルを生成されてしまうという問題がある。
【００５９】
そこで、本実施形態によれば、Ｓ１０４の後ろで「画像形成装置１００はシミュレータであるか否か」をヒープダンプファイル生成判定部３０８で判定するＳ３０２の処理を追加する。そして、この判定結果がシミュレータではない場合（製品の場合）は従来と同じくヒープダンプファイルを生成し（Ｓ１０８）、シミュレータの場合はＳ１０５の判定に進む。なお、シミュレータか否かの情報（第５情報）はＲＯＭ１０３に予め格納しておき、ヒープダンプファイル生成判定部３０８がこの値を参照することで判定してもよい。これにより、ＭＦＰが製品開発中であっても、ヒープダンプファイルの生成を行わなくすることができる。
【００６０】
以上説明したように、本実施形態に係る画像形成装置は、２つの条件（Ｓ３０１とＳ３０２）を追加することで、無駄なヒープダンプファイルが生成されることをさらに防ぐことが可能となる。なお、上記２つの条件（Ｓ３０１とＳ３０２）は、何れか一方のみを追加するようにしてもよい。
【００６１】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００６２】
１０１：ＣＰＵ、１０２：ＲＡＭ、１０３：ＲＯＭ、１０４：ＨＤＤ、２０２：ＪａｖａＶＭ、２０３：アプリプラットフォーム、３０１：バイトコード実行部、３０２：クラスローダ管理部、３０３：ＧＣ実行部、３０４：メモリ制御部、３０５：ヒープダンプファイル情報生成部、３０６：ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ発生部、３０７：アプリ管理部、３０８：ヒープダンプファイル生成判定部、３０９：ヒープダンプファイル生成実行部
【図１】
2016095792.tif 000003
【図２】
2016095792.tif 000004
【図３】
2016095792.tif 000005
【図４】
2016095792.tif 000006
【図５】
2016095792.tif 000007
【図６】
2016095792.tif 000008
【図７】
2016095792.tif 000009
【図８】
2016095792.tif 000010
【図９】
2016095792.tif 000011