(57)【要約】【課題】アプリケーションのリソースリークが増えてくると、アプリケーションの実行速度が低下したり、アプリケーションの処理を正しく行えなかったり、画像処理装置がハングアップしたりなどの問題が発生する。【解決手段】画像処理装置がスリープモードに移行する際に、画像処理装置のリソースが枯渇しているかどうかを判定し、画像処理装置のリソースが枯渇し、かつ、実行中や実行待ちのジョブがない場合に画像処理装置を再起動させる。【選択図】図２
2018182378.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションをインストールし、実行できる画像処理装置であって、
通常の動作モードと電力供給を部分的に停止するスリープモードとで動作モードを切り替える電源管理手段と、
前記電源管理手段による通常の動作モードとスリープモードとの切り替えの際に、アプリケーションの使用するリソースの量が、前記アプリケーションについて宣言されたリソースの量を超えるリソース枯渇が発生したか否かを判断し、リソース枯渇と判断した場合には前記画像処理装置を再起動させる再起動手段と
を有することを特徴とする画像処理装置。
【請求項２】
請求項１に記載の画像処理装置であって、
前記再起動手段は、前記電源管理手段による通常の動作モードとスリープモードとの切り替えの際に、アプリケーションの使用するリソースの量と、前記アプリケーションについて宣言されたリソースの量とを比較することでリソース枯渇が発生したか否かを判断し、前記アプリケーションの使用するリソースの量の方が大きい場合には、リソース枯渇と判断することを特徴とする画像処理装置。
【請求項３】
請求項１に記載の画像処理装置であって、
前記アプリケーションの実行中に、前記アプリケーションの使用するリソースの量と、前記アプリケーションについて宣言されたリソースの量とを比較することでリソース枯渇が発生したか否かを判断し、前記リソース枯渇が生じていると判断した場合には前記再起動手段に前記リソース枯渇を通知する通知手段をさらに有し、
前記再起動手段は、前記通知手段による通知を受けた際には前記リソース枯渇が生じたことを記録し、
前記電源管理手段による通常の動作モードとスリープモードとの切り替えの際に、前記前記リソース枯渇が生じたことが記録されている場合には、リソース枯渇と判断することを特徴とする画像処理装置。
【請求項４】
請求項１に記載の画像処理装置であって、
前記アプリケーションの実行中に、前記アプリケーションの使用するリソースの量と、前記アプリケーションについて宣言されたリソースの量とを比較することでリソース枯渇が発生したか否かを判断し、前記リソース枯渇が生じていると判断した場合には前記再起動手段に前記リソース枯渇を通知する通知手段をさらに有し、
前記再起動手段は、前記通知手段による通知を受けた際には、前記アプリケーションが使用するリソースの合計が所定値を超えたなら前記リソース枯渇が生じたことを記録し、
前記電源管理手段による通常の動作モードとスリープモードとの切り替えの際に、前記前記リソース枯渇が生じたことが記録されている場合には、リソース枯渇と判断することを特徴とする画像処理装置。
【請求項５】
請求項２乃至４のいずれか一項に記載の画像処理装置であって、
前記アプリケーションの使用する前記リソースの量と、前記アプリケーションについて宣言されたリソースの量とは、それぞれの合計で比較されることを特徴とする画像処理装置。
【請求項６】
請求項２乃至４のいずれか一項に記載の画像処理装置であって、
前記アプリケーションの使用する前記リソースの量と、前記アプリケーションについて宣言されたリソースの量とは、アプリケーションごと、かつリソース種別ごとに比較されることを特徴とする画像処理装置。
【請求項７】
請求項１乃至６のいずれか一項に記載の画像処理装置であって、
前記再起動手段は、リソース枯渇と判断した場合に、実行中のジョブ及び実行を待機しているジョブがある場合には、当該ジョブの実行の完了の後、前記画像処理装置を再起動させることを特徴とする画像処理装置。
【請求項８】
請求項１乃至７のいずれか一項に記載の画像処理装置であって、
前記再起動手段は、リソース枯渇と判断した場合に、現在の時刻から前記画像処理装置の再起動を開始した場合に、前記再起動が完了するまえに実行時刻が設定されたタイマータスクがスケジュールされていない場合には、前記画像処理装置を再起動させることを特徴とする画像処理装置。
【請求項９】
請求項１に記載の画像処理装置であって、
前記再起動手段は、メモリ不足エラーが発生した場合にリソース枯渇と判断することを特徴とする画像処理装置。
【請求項１０】
請求項１乃至９のいずれか一項に記載の画像処理装置であって、
前記再起動手段は、前記通常の動作モードから前記スリープモードへ移行する場合に、前記リソース枯渇か否かを判断することを特徴とする画像処理装置。
【請求項１１】
請求項１乃至１０のいずれか一項に記載の画像処理装置であって、
前記再起動手段は、前記通常の動作モードへ前記スリープモードから移行する場合に、前記リソース枯渇か否かを判断することを特徴とする画像処理装置。
【請求項１２】
アプリケーションをインストールし、実行できるコンピュータを、
通常の動作モードと電力供給を部分的に停止するスリープモードとで動作モードを切り替える電源管理手段と、
前記電源管理手段による通常の動作モードとスリープモードとの切り替えの際に、アプリケーションの使用するリソースの量が、前記アプリケーションについて宣言されたリソースの量を超えるリソース枯渇が発生したか否かを判断し、リソース枯渇と判断した場合には前記コンピュータを再起動させる再起動手段と
して機能させるためのプログラム。
【請求項１３】
通常の動作モードと電力供給を部分的に停止するスリープモードとで動作モードを切り替える電源管理手段を有しており、アプリケーションをインストールし、実行できる画像処理装置を制御する制御方法であって、
前記電源管理手段による通常の動作モードとスリープモードとの切り替えの際に、アプリケーションの使用するリソースの量が、前記アプリケーションについて宣言されたリソースの量を超えるリソース枯渇が発生したか否かを判断し、
リソース枯渇と判断した場合には前記画像処理装置を再起動させる
ことを特徴とする画像処理装置の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えばアプリケーションの使用するリソース（メモリ、スレッド、ソケット、ファイルディスクリプタ（FD）等）が枯渇した場合に、ユーザビリティを低下させずにリソース枯渇を解消する画像処理装置およびその制御方法とプログラムに関する。
【背景技術】
【０００２】
多機能周辺機器(MFP)といった画像処理装置においてJava（登録商標）などで構築されたアプリケーションを実行するアプリケーション実行環境をもち、アプリケーションのインストールにより機能を追加できるものが一般的になっている。アプリケーションは画像処理装置のリソース(メモリ、スレッド、ソケット、FD等)を使用して動作する。アプリケーションの使用するリソースはアプリケーションが該当リソースの使用を終了すると、アプリケーション実行環境のGC(ガーベージコレクション)やアプリケーションによる明示的なリソース解放により解放される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第5119047号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
アプリケーションがバグなどにより確保したリソースをつかんだままの場合、そのリソースはGC対象にならない。これを一般的にリソースリークと呼ぶ。画像処理装置がもつリソースは有限であるため、リソースリークが増えてくると、アプリケーションがリソースを使用する処理を行おうとしたときにリソースの確保ができず、エラーや処理を進められない状態が発生する。この状態がリソース枯渇である。リソース枯渇になるとアプリケーションの実行速度が低下したり、アプリケーションの処理を正しく行えなかったり、画像処理装置がハングアップしたりなどの問題が発生する。画像処理装置を再起動し、初期化することによりリークしたリソースは解放されるため、再起動によってこの問題を解決することは可能であるが、ユーザの使用中に再起動をおこなうことはユーザビリティを著しく低下させる。
【０００５】
本発明は上記従来例に鑑みて成されたもので、ユーザビリティに与える影響を抑えつつリソースリークを解消し、安定して動作する画像処理装置およびその制御方法とプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成するために本発明は以下の構成を有する。
【０００７】
アプリケーションをインストールし、実行できる画像処理装置であって、
通常の動作モードと電力供給を部分的に停止するスリープモードとで動作モードを切り替える電源管理手段と、
前記電源管理手段による通常の動作モードとスリープモードとの切り替えの際に、アプリケーションの使用するリソースの量が、前記アプリケーションについて宣言されたリソースの量を超えるリソース枯渇が発生したか否かを判断し、リソース枯渇と判断した場合には前記画像処理装置を再起動させる再起動手段と
を有することを特徴とする画像処理装置。
【発明の効果】
【０００８】
本発明によれば、ユーザビリティに与える影響を抑えつつリソースリークを解消し、安定して動作する画像処理装置及びその制御方法とプログラムを提供できる。
【図面の簡単な説明】
【０００９】
【図１】本発明が実施されるシステムの構成を示す図である。
【図２】実施形態１〜５のソフトウェアの構成を示す図である。
【図３】実施形態１、３、４、６のアプリリソース管理部の構成を示す図である。
【図４】実施形態１〜６のJob管理部の構成を示す図である。
【図５】実施形態１〜６のリソース枯渇判定部の処理のフローチャートである。
【図６】実施形態１のリソース枯渇判定部の処理のリソース枯渇チェック処理の詳細のフローチャートである。
【図７】実施形態２のアプリリソース管理部の構成を示す図である。
【図８】実施形態２のリソース枯渇判定部の処理のリソース枯渇チェック処理の詳細のフローチャートである。
【図９】実施形態３でのリソースの変化の例を示すグラフである。
【図１０】実施形態３のリソースイベントのリスナ登録、イベント発行のフローチャートである。
【図１１】実施形態３のリソース枯渇判定部の処理のリソース枯渇チェック処理の詳細のフローチャートである。
【図１２】実施形態４のリソース枯渇判定部の処理のリソース枯渇チェック処理の詳細のフローチャートである。
【図１３】実施形態５のリソース枯渇判定部の処理のリソース枯渇チェック処理の詳細のフローチャートである。
【図１４】実施形態のソフトウェアの構成を示す図である。
【図１５】実施形態６のリソース枯渇判定部の処理のリソース枯渇チェック処理の詳細のフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための形態について図面を用いて説明する。
［実施形態１］
図１は本実施形態のシステムの構成を示す図である。画像処理装置１００は本実施形態に係る発明を実現するソフトウェアを実行するCPU１０１、本実施形態に係る発明を実現するソフトウェアを保存しているROM１０２、本実施形態に係る発明を実現するソフトウェアを実行するRAM１０３、本実施形態に係る発明を実現するソフトウェアがデータを保存する外部記憶装置１０４、ユーザが操作をおこなうUI１０５、ネットワークI/F制御部１０７、印刷をおこなう印刷エンジン１０８から構成される。UI１０５は液晶タッチパネルや液晶パネルとハードキー組み合わせたものとして実現されている。上記画像処理装置１００の各構成要素はバス１０６によって相互に接続されておりデータのやり取りをおこなう。画像処理装置１００はネットワークI/F制御部１０７によってネットワーク１０９に接続されている。
【００１１】
＜ソフトウェアの構成＞
図２は本実施形態のソフトウェアの構成を示す図である。図２の各ソフトウェアモジュールは、ＣＰＵ１０１がＲＡＭ１０３等のメモリに格納されたプログラムを実行することで実現される。画像処理装置のハードウェア２０１上にオペレーティングシステム（OS）２０２が実装されている。電源管理部２０８は機器の通常モードからスリープモードへの動作モードの遷移、スリープモードからの復帰、シャットダウンの処理などを管理するモジュールである。電源管理部２０８は、例えば所定時間にわたってユーザの操作や外部から印刷要求がない場合、消費電力を抑えるため画像処理装置１００をスリープ状態にする。電源管理部２０８が管理するスリープモードには、スリープ時の消費電力に応じて以下の3つのサブモードがある。いずれにしても電力供給を部分的に停止する。
(1)UI１０５の液晶パネルだけ消灯するパネルスリープ(消費電力高)
(2)UI１０５に加えて画像処理装置の印刷エンジン１０８を停止するエンジンスリープ(消費電力中)
(3)UI１０５、印刷エンジン１０８に加えてCPU１０１の動作をとめるディープスリープ(消費電力低)
画像形成装置１００は、たとえば時間の経過に応じてパネルスリープからディープスリープへ、さらにエンジンスリープへと順次遷移してもよいし、スリープ時には予めユーザが選択したサブモードに移行してもよい。パネルスリープやエンジンスリープの場合、画像処理装置１００はアプリケーション２０９やネットワーク１０９から印刷Jobを受信し、印刷を行うことができる。通常の運転モードからスリープモードへと遷移する際には、電源管理部２０８はリソース枯渇判定部２０６を含む必要な各モジュールへと、スリープモードへの移行イベントを示すメッセージを送信する。リソースには、たとえばメモリ、スレッド、ソケット、FD等のリソース種別がある。
【００１２】
Job管理部２０７は印刷Jobの実行を行うモジュールである。JavaVM２０３はJavaのバイトコードを実行するための仮想マシンである。本実施形態ではJavaVM２０３を例に記載しているが、他のアプリ実行環境でもよい。
【００１３】
アプリケーションプラットフォーム２０４はアプリケーション２０９の起動、停止などのライフサイクル管理をおこなう。アプリケーションプラットフォーム２０４はアプリケーション２０９がJob管理部２０７にJobを投入するAPIを持つ。アプリケーションプラットフォーム２０４は電源管理部２０８からのスリープ移行/復帰のイベントを受信するAPI、受信したイベントをアプリケーション２０９に通知するためのAPIを持つ。アプリケーションプラットフォーム２０４はアプリケーション２０９の使用するリソースを管理するアプリリソース管理部２０５、およびリソースが枯渇しているかどうかを判定するリソース枯渇判定部２０６を持つ。
【００１４】
＜アプリリソース管理部の構成＞
図３はアプリリソース管理部２０５の構成を示す図である。アプリリソース管理部２０５はリソースの種類毎にアプリケーション２０９が宣言する最大使用量を管理する宣言使用量合計テーブル３０１を持つ。さらにリソースの種類毎にリソースの種類毎に実際にアプリケーション２０９が使用しているリソース量の合計を管理する実使用量合計テーブル３０２を持つ。アプリケーション２０９によるリソースの最大使用量等の宣言は、たとえばアプリケーションについての情報が記述されたマニフェストファイルなどで行うことができる。たとえばアプリケーション２０９のインストール時に、マニフェストファイルに記載されたリソース最大使用量を宣言使用量合計テーブル３０１に複製することで、宣言使用量合計テーブル３０１にリソース最大使用量を設定できる。アプリリソース管理部２０５は、アプリケーションのリソースを管理するプログラムであってもよいが、たとえばオペレーティングシステム２０２が、アプリケーションに割り当てたリソースの管理に使用する、宣言使用量合計テーブル３０１と実使用量合計テーブル３０２とを含むテーブルの集まりであってもよい。
【００１５】
＜ジョブ管理部の構成＞
図４はJob管理部２０７の構成を示す図である。Job管理部２０７は現在実行中のJobの情報４０１とこれから実行するJobの情報を保持するJobのキュー４０２から構成される。
【００１６】
＜リソース枯渇判定部による処理＞
図５はリソース枯渇判定部２０６の処理を示すフローチャートである。このフローは、ソフトウェア構成上はリソース枯渇判定部２０６により、ハードウェア構成上はＣＰＵ１０１により実行される。
【００１７】
電源管理部２０８からのスリープ移行のイベントを受けるとリソース枯渇判定部２０６はスリープ移行処理を開始する（ステップＳ５０１）。まず、リソース枯渇判定部２０６はリソース枯渇チェックを行う（ステップＳ５０２）。リソース枯渇チェック（ステップＳ５０２）はJavaVM２０３の保持する残りリソースがアプリケーション２０９を実行するのに十分であるかを判定する処理である。たとえば未使用リソースの量がある一定値を切ったらリソース枯渇と判断する。またはアプリケーションが、そのアプリケーションが宣言している使用量を超えてリソースを使用していたらリソース枯渇と判断する。次にリソース枯渇判定部２０６はステップ５０２のリソース枯渇チェックの結果を調べる(ステップＳ５０３)。リソース枯渇でなければステップ５０４に遷移する。リソース枯渇であればステップＳ５０６に遷移する。
【００１８】
ステップＳ５０４でリソース枯渇判定部２０６はアプリケーションプラットフォーム２０４、およびアプリケーション２０９のスリープ移行処理を呼び出し(ステップＳ５０４)、スリープ移行処理を終了する（ステップＳ５０５）。
【００１９】
ステップＳ５０６でリソース枯渇判定部２０６はJob管理部２０７の実行中のJobの情報４０１からJobの状態を取得する（ステップＳ５０６）。次にリソース枯渇判定部２０６は、ステップＳ５０６でジョブの状態として「Job実行中」が取得できたのであればステップＳ５０６に遷移する。Job実行中のジョブの状態が取得できなければ、すなわち実行中のジョブがなければステップＳ５０８に遷移する（ステップＳ５０７）。
【００２０】
リソース枯渇判定部２０６はJob管理部２０７のJobのキュー４０２に実行予定のJobがあるかを調べる（ステップＳ５０８）。リソース枯渇判定部２０６は、ステップＳ５０８の結果が、キューにJob有りであればステップＳ５０６に遷移する。キューにJob無しであればステップＳ５１０に遷移する（ステップＳ５０９）。リソース枯渇と判断された場合には、ステップＳ５０６−Ｓ５０９のループで、実行中のジョブやキューで待機しているジョブの実行完了を待つ。
【００２１】
実行予定のジョブが無ければリソース枯渇判定部２０６は電源管理部２０８に再起動を要求し（ステップＳ５１０）、スリープ移行処理を終了する（ステップＳ５０５）。
【００２２】
図６はリソース枯渇チェック（ステップＳ５０２）の詳細な処理を示すフローチャートである。リソース枯渇判定部２０６はリソース枯渇チェック処理を開始する（ステップＳ６０１）。リソース枯渇判定部２０６はアプリリソース管理部２０５の実使用量合計テーブル３０２からJavaVM２０３が使用している各リソースの量を取得する（ステップＳ６０２）。次にリソース枯渇判定部２０６はアプリリソース管理部２０５の宣言使用量合計テーブル３０１からアプリが最大使用量と宣言しているリソースの合計値を取得する（ステップＳ６０３）。次にステップ６０２で取得した、JavaVM２０３が使用しているリソース量からアプリケーションプラットフォーム２０４の使用量を引いた値がステップＳ６０３で取得したリソースの合計値を超えているかをリソース種類毎に調べる（ステップＳ６０４）。超えているリソースがあればステップＳ６０５に遷移する。超えていなければステップＳ６０６に遷移し、リソース枯渇チェック処理を終了する（ステップＳ６０６）。ステップＳ６０５ではリソース枯渇チェックの結果としてリソース枯渇を返し（ステップＳ６０５）、リソース枯渇チェック処理を終了する（ステップＳ６０６）。
【００２３】
以上の手順により、スリープモードへの移行の直前にリソース枯渇か否か判定する。そして、リソース枯渇と判定された場合には、待機中のジョブがすべて完了した後で、画像形成装置１００をステップＳ５１０で再起動する。これによってリークしたリソースはすべて解放され起動時の状態にもどるためリソース枯渇による障害の発生を抑制することができる。さらにユーザが操作をしている場合、または実行すべきJob存在している場合は再起動をおこなわないため、ユーザビリティの低下も抑制することができる。なおこのフローチャートではスリープ移行時に処理をおこなっているが、スリープ復帰時に処理をおこなってもいい。
【００２４】
［実施形態２］
実施形態１では前アプリケーションの使用するリソースの合計値をつかって枯渇しているかのチェックをおこなうため、リソースリークのバグを持たないアプリケーションの動作によりリソースリークが隠されてしまうことがある。そのためリソースリークの発見が遅くなるという課題がある。そこで実施形態２ではアプリケーション毎にリソース枯渇が発生しているかを調べる方法について説明する。実施形態２は、図３に示したアプリリソース管理部２０６の構成を図７で、図６に示したリソース枯渇チェック処理を図８で示す以外は実施形態１と同様である。
【００２５】
図７は実施形態２のアプリリソース管理部２０５の構成を示す図である。アプリリソース管理部２０５はリソース種類毎かつアプリ毎に、宣言使用量７０２と実使用量７０３とを管理するリソーステーブル７０１をもつ。宣言使用量にはたとえば各アプリケーションのマニフェストファイルで宣言されたリソース量が記載され、実使用量にはたとえば各アプリケーションによるリソースの要求に対してオペレーティングシステム２０２やアプリリソース管理部２０６が割り当てたリソースの使用量が記載される。
【００２６】
図８は実施形態２のリソース枯渇チェック（ステップＳ５０２）の詳細な処理を示すフローチャートである。リソース枯渇判定部２０６はリソース枯渇チェック処理を開始する（ステップＳ８０１）。リソース枯渇判定部２０６はアプリリソース管理部２０５のリソーステーブル７０１の情報をリソース毎、アプリ毎に調べていく。たとえばリソーステーブル７０１の行に上から順次着目する。着目した行のアプリを着目アプリ、着目した行のリソースを着目リソースと呼ぶことにする。リソース枯渇判定部２０６はアプリリソース管理部２０５のリソーステーブル７０１から着目リソースの実使用量７０３を取得する（ステップＳ８０２）。次にリソース枯渇判定部２０６はアプリリソース管理部２０５のリソーステーブル７０１から着目リソースの宣言使用量７０２を取得する（ステップＳ８０３）。リソース枯渇判定部２０６はステップＳ８０２で取得した実使用量とステップＳ８０３で取得した宣言使用量を比較し、実使用量が大きい場合はステップＳ８０５に遷移する。小さい場合はステップＳ８０６に遷移する（ステップＳ８０４）。
【００２７】
ステップＳ８０５でリソース枯渇判定部２０６はリソース枯渇チェックの結果としてリソース枯渇を返し（ステップＳ８０５）、リソース枯渇チェック処理を終了する（ステップＳ８０７）。ステップＳ８０６でリソース枯渇判定部２０６はリソーステーブル７０１の末尾までチェックをおこなったかを調べ（ステップ８０Ｓ６）、末尾でなければ着目リソースを次に移してステップＳ８０２に遷移し、次のリソースのチェックを行う。末尾であればステップＳ８０７に遷移し、リソース枯渇チェック処理を終了する（ステップＳ８０７）。
【００２８】
以上の処理により個々のアプリケーションによるリソースリークを早期に検知してリソース枯渇から復帰することができる。
【００２９】
［実施形態３］
図９はアプリケーションの使用リソースの変化の一例を表すグラフである。アプリケーションAとアプリケーションBが動作していて、アプリケーションBがリソースリークを起こしているとする。アプリケーションBがリソースリークをしている場合、アプリケーションAは自身の宣言使用量内でリソースを使用していたとしても実使用量が宣言使用量の合計９０１を超える時期９０２がありえる。
【００３０】
しかし、アプリケーションAはリソースリークを起こしていないため、時間の経過やユーザの操作によってアプリケーションAの使用リソースが解放され、宣言使用量の合計９０１以下の実使用量になることがある。このとき電源管理部２０８がスリープ移行を指示し、リソース枯渇判定部２０６がリソース枯渇チェック（ステップＳ５０２）を行うと、アプリケーションBがリソースリークを起こしているにも関わらずリソースが枯渇していることを検知することができない。そこで本実施形態では、使用リソース量が宣言リソース量を超えたことを記録し、その記録に基づいてリークしたリソースを解放する仕組みを提供する。
【００３１】
＜イベントリスナの登録＞
図１０は実施形態３のJavaVM２０３、リソース枯渇判定部２０６の処理を示すフローチャートである。JavaVM２０３の機能としてJavaVM２０３の使用するリソース量が一定の閾値を超えたらイベントを発行するというものがある。ソース枯渇判定部２０６は画像処理装置１００の起動時にリソースイベント登録処理を開始する（ステップＳ１００１）。リソース枯渇判定部２０６はアプリリソース管理部２０５の宣言使用量合計テーブル３０１からアプリケーション２０９が宣言する最大使用量の合計値をリソース種類毎に取得する(ステップＳ１００２)。リソース枯渇判定部２０６は宣言最大使用量の合計値とアプリケーションフレームワーク２０３の使用量とを足したリソース量をJavaVMにリソース種類毎に登録する（ステップＳ１００３）。また必要に応じて、リソースイベントの発生に応じて呼び出されるイベントリスナも登録する。イベントリスナはたとえばリソース枯渇判定部２０６自身でよい。これにより、JavaVMは取得した宣言最大使用量の合計値のリソースを使用したときにイベント発行するようになる。次にリソースイベント登録処理を終了する（ステップＳ１００４）。
【００３２】
JavaVM２０３はアプリケーション２０９からオブジェクトの生成を要求されるとオブジェクト生成処理を開始する（ステップＳ１０１０）。JavaVM２０３はリソースを確保し（ステップＳ１０１１）、オブジェクトを生成する（ステップＳ１０１２）。JavaVM２０３は、JavaVM２０３の使用しているリソース量がステップＳ１００３で登録された使用量を超えているかを調べる(ステップＳ１０１３)。超えていたら、ステップＳ１０１４に遷移し、リソースイベントを発行し（ステップＳ１０１４）、オブジェクト生成処理を終了する（ステップＳ１０１５）。超えていなければステップＳ１０１５に遷移しオブジェクト生成処理を終了する（ステップＳ１０１５）。
【００３３】
＜リソース枯渇判定処理＞
図１１はリソースイベントを受信したときおよびスリープ移行時のリソース枯渇判定部２０６の処理を示すフローチャートである。リソース枯渇判定部２０６はリソースイベントを受信すると、リソースイベントフラグ処理を開始する(ステップＳ１１０１)。リソース枯渇判定部２０６はリソースイベントフラグをTrueに設定し（ステップＳ１１０２）、リソースイベントフラグ処理を終了する（ステップＳ１１０３）。
【００３４】
また電源管理部２０８からスリープ移行のイベントを受け取るとリソース枯渇判定部２０６は図５のようにスリープ移行処理を開始し、リソース枯渇チェック（ステップＳ５０２）を行う。リソース枯渇判定部２０６はリソース枯渇チェック処理を開始する（ステップＳ１１０４）。リソース枯渇判定部２０６はリソースイベントフラグをチェックし（ステップＳ１１０５）、TrueであればステップＳ１１０６に遷移する。TrueでなければステップＳ１１０７に遷移してリソース枯渇チェック処理を終了する（ステップＳ１１０７）。ステップＳ１１０６でリソース枯渇判定部２０６はリソース枯渇を返し、リソース枯渇チェック処理を終了する（ステップ１１０７）。
【００３５】
以上の処理により、リソースリークを起こさないアプリのリソース解放により、スリープ移行時には実使用量が宣言使用量を下回る場合にもリソースリークが生じたことを検知して再起動を行うことにより、隠れたリソースリークからの復帰を可能とする。
【００３６】
［実施形態４］
実施形態１〜３では画像処理装置１００の総リソース量にくらべアプリケーションの宣言使用量が小さい場合、画像処理装置が大量のリソースを残していてもリソース枯渇と判断されてしまう。そのため再起動回数が増えてユーザビリティが低下する課題がある。本実施形態ではそのような課題を解決する。本実施形態の図１２は、実施形態３の図１１に代わるもので、他の構成は実施形態３と同様であってもよい。
【００３７】
本実施形態では、図１０のようにリソース枯渇判定部２０６はリソースイベントリスナの登録処理を行う。またJavaVMはリソースイベントを発行する。
【００３８】
図１２はリソースイベントを受信したときおよびスリープ移行時のリソース枯渇判定部２０６の処理を示すフローチャートである。リソース枯渇判定部２０６はリソースイベントを受信すると、リソース監視スレッド開始処理を開始する(ステップＳ１２０１)。リソース枯渇判定部２０６はリソース監視スレッドを生成、開始し（ステップＳ１２０２）、リソース監視スレッド開始処理を終了する（ステップＳ１２０３）。リソース枯渇判定部２０６は生成したリソース監視スレッドによりリソース監視処理を開始する（ステップＳ１２０４）。
【００３９】
リソース枯渇判定部２０６はあらかじめ決められた監視間隔分の時間、スレッドを一時停止する（ステップＳ１２０５）。一時停止が終了するとリソース枯渇判定部２０６は使用リソース量があらかじめ決められた規定値を超えているかをチェックする（ステップＳ１２０６）。規定値はリソース枯渇判定部２０６が保持している。規定値は利用可能なリソース量のたとえば90%等というように決めてもよいし、監視間隔時間あたりの使用リソース量の増加量の変化で決めてもよい。超えていなければステップＳ１２０５に遷移する。超えていればステップＳ１２０７に遷移する。リソース枯渇判定部２０６は、使用リソース量が規定値（あるいは所定値）を超えていればリソース枯渇フラグをTrueに設定し（ステップＳ１２０７）、リソース監視処理を終了する（ステップＳ１２０８）。リソース監視スレッドを消滅させてもよい。
【００４０】
電源管理部２０８からスリープ移行のイベントを受け取るとリソース枯渇判定部２０６は図５のようにスリープ移行処理を開始し、リソース枯渇チェック（ステップＳ５０２）を行う。リソース枯渇判定部２０６はリソース枯渇チェック処理（ステップＳ５０２）を開始する（ステップＳ１２１０）。
【００４１】
リソース枯渇判定部２０６はリソース枯渇フラグをチェックし（ステップＳ１２１１）、Trueであればステップ１２１２に遷移する。Trueでなければステップ１２１３に遷移してリソース枯渇チェック処理を終了する（ステップＳ１２１３）。ステップ１２１２でリソース枯渇判定部２０６はリソース枯渇を返し(ステップＳ１２１２)、リソース枯渇チェック処理を終了する（ステップＳ１２１３）。
【００４２】
以上の処理により、アプリケーションの使用リソース量がその宣言リソース量を超えることがあっても直ちにリソース枯渇と判定せず、使用リソース量が所定値をこえたときにリソース枯渇が生じたことを記録しておく。そしてスリープモードへの移行時に、待機ジョブがないことなどの再起動条件を満たしていれば、画像処理装置を再起動する。この構成により、JavaVMの使用可能リソースにくらべアプリの宣言するリソース使用量の合計が非常に小さいなどの場合に再起動の実行を遅らせ、不要な再起動を減らしユーザビリティを向上させることができる。
【００４３】
［実施形態５］
実施形態１〜４において、アプリケーションのバグの内容によってはリソースリークが急激に進行し、リソース枯渇チェックよりまえにOutOfMemoryErrorが発生してしまうことがある、という課題がある。JavaVM２０３が実行中にリソース枯渇し、オブジェクトの生成ができなくなるとOutOfMemoryErrorが発生し、以後のJavaVM２０３の動作は不安定になる。本実施形態ではそのような問題に対応する。
【００４４】
図１３はOutOfMemoryErrorが発生したときおよびスリープ移行時のリソース枯渇判定部２０６の処理を示すフローチャートである。図１３は、実施形態３の図１１または実施形態４の図１２に代えて用いてもよいし、それらに追加的に加えてもよい。ただし、追加する場合には、図１２のステップＳ１２１０〜Ｓ１２１３と図１３のステップＳ１３０５〜Ｓ１３０８は同じ処理内容となるので、いずれか一方のみでよい。このほかの構成は、実施形態３または実施形態４と同一となる。また追加の場合には、ステップＳ１３０１〜Ｓ１３０４は、独立したスレッドで実行されるのが望ましい。
【００４５】
アプリケーションプラットフォーム２０４が起動され、リソース枯渇判定部２０６が動作を開始すると、リソース枯渇判定部２０６はリソース枯渇フラグ処理を開始する（ステップＳ１３０１）。リソース枯渇判定部２０６はJavaVM２０３からOutOfMemoryError（メモリ不足エラー）が発生するのを待つ（ステップＳ１３０２）。
【００４６】
リソース枯渇判定部２０６はOutOfMemoryErrorを受けるとリソース枯渇フラグをTrueに設定し（ステップＳ１３０３）、ソース枯渇フラグ処理を終了する（ステップＳ１３０４）。
【００４７】
電源管理部２０８からスリープ移行のイベントを受け取るとリソース枯渇判定部２０６は図５のようにスリープ移行処理を開始し、リソース枯渇チェック（ステップＳ５０２）を行う。リソース枯渇判定部２０６はリソース枯渇チェック処理（ステップＳ５０２）を開始する（ステップＳ１３０５）。リソース枯渇判定部２０６はリソース枯渇フラグをチェックし（ステップＳ１３０６）、TrueであればステップＳ１３０７に遷移する。TrueでなければステップＳ１３０８に遷移してリソース枯渇チェック処理を終了する（ステップＳ１３０８）。ステップＳ１３０７でリソース枯渇判定部２０６はリソース枯渇を返し(ステップＳ１３０７)、リソース枯渇チェック処理を終了する（ステップＳ１３０８）。
【００４８】
以上の処理によりリソース枯渇によるOutOfMemoryErrorが発生するような状況になったとき、ユーザビリティを低下させずに再起動を行うことができる。
【００４９】
［実施形態６］
実施形態１〜５の方法では再起動によりアプリケーション２０９が登録したタイマータスクが実行できない場合があるという課題がある。本実施形態ではその課題を解決する。
【００５０】
図１４は実施形態６のソフトウェアの構成を示す図である。タイマーサービス１４０１はアプリケーション２０９にタイマー機能を提供するモジュールである。タイマーサービス１４０１は予約されたタスクを管理するためのタイマータスクリスト１４０４をもつ。タイマータスクリスト１４０４はタスクを実行する実行時刻１４０５、実行するタスクオブジェクト１４０５から構成される。アプリケーション２０９が実行時刻とタイマーサービス１４０１がコールバックするタスクオブジェクトの登録１４０２を行う。タイマーサービス１４０１はタイマータスクリスト１４０４に登録された時間になると対応するタスクオブジェクトの呼び出し１４０３を行う。
【００５１】
図１５は実施形態６のリソース枯渇判定部２０６のリソース枯渇チェック（ステップＳ５０２）の処理を示すフローチャートである。電源管理部２０８からスリープ移行のイベントを受け取るとリソース枯渇判定部２０６は図５のようにスリープ移行処理を開始し、リソース枯渇チェック（ステップＳ５０２）を行う。リソース枯渇判定部２０６はリソース枯渇チェック処理（ステップＳ５０２）を開始する（ステップＳ１５０１）。リソース枯渇判定部２０６はアプリリソース管理部２０５の実使用量合計テーブル３０２からJavaVM２０３が使用している各リソースの量を取得する（ステップＳ１５０２）。
【００５２】
次にリソース枯渇判定部２０６はアプリリソース管理部２０５の宣言使用量合計テーブルからアプリが最大使用量と宣言しているリソースの合計値を取得する（ステップＳ１５０３）。次にステップＳ１５０２で取得したJavaVM２０３が使用しているリソース量からアプリケーションプラットフォーム２０４の使用量を引いた値がステップＳ１５０３で取得したリソースの合計値を超えているかをリソース毎に調べる（ステップＳ１５０４）。超えていればステップＳ１５０５に遷移する。超えていなければステップＳ１５１０に遷移し、リソース枯渇チェック処理を終了する（ステップＳ１５１０）。
【００５３】
ステップＳ１５０５でリソース枯渇判定部２０６はタイマーサービス１４０１からタイマータスクリスト１４０４を取得する（ステップＳ１５０５）。以後、リソース枯渇判定部２０６はタイマータスクリストに入っている時間をタスクごとに順次調べていく。ステップＳ１５０６でタイマータスクリストの末尾まで調べたかを判定する（ステップＳ１５０６）。末尾まできていればステップＳ１５０９に遷移する。末尾まできていなければステップＳ１５０７に遷移する。
【００５４】
ステップＳ１５０７でリソース枯渇判定部２０６はタイマータスクの実行時刻を取得する（ステップＳ１５０７）。次にステップＳ１５０７で取得したタイマータスク実行時刻が現在時刻に再起動に必要な時間を足した時刻の前か後かを判定する（ステップＳ１５０８）。この判定は、タイマータスクの実行開始時刻が、今から画像処理装置を再起動してそれが完了した後の時刻であるか否かを判定している。再起動に必要な時間はあらかじめ値を設定しておいてもよいし、前回のシャットダウン時間と起動時間の和でもよいし、デバイスの設定値から積み上げた時間でもよい。後であればステップＳ１５０６に遷移する。前であればステップＳ１５１０に遷移する。
【００５５】
ステップＳ１５０９ではリソース枯渇チェックの結果としてリソース枯渇を返し（ステップＳ１５０９）、リソース枯渇チェック処理を終了する（ステップＳ１５１０）。
【００５６】
上記処理により、アプリケーションの登録しているタイマータスクの実行がリソース枯渇による再起動に阻害されることがないため、ユーザビリティを低下させずに再起動を実行できる。
【００５７】
なおステップＳ１５０６〜Ｓ１５０７の代わりに、タイマータスクリストに登録された実行時刻のうち最先の時刻を取得し、ステップＳ１５０８ではその時刻を、再起動完了後の時刻と比較してもよい。この判定の結果、最先の実行時刻の方が遅いと判定されれば、全てのタイマータスクに対して再起動完了よりも遅い実行時刻が設定されていると判定できる。したがってその場合にはステップＳ１５０９を実行すればよい。また、最先の実行時刻の方が早いと判定されれば、再起動を行っている期間に実行開始時刻が設定されたタイマータスクが少なくとも一つはあることが分かる。その場合にはリソース枯渇とはしない。
【００５８】
さらに、再起動を行っている期間に実行開始時刻が設定されたタイマータスクがスケジュールされている場合には、そのタスクの完了を待って再度ステップＳ１５０５から実行してもよい。そのようにすることで、タイマータスクを妨害することなく再起動を行う機会がさらに増加する。
【００５９】
［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００６０】
２０１ ハードウェア、２０１ OS、２０３ JavaVM、２０４ アプリケーションプラットフォーム、２０５ アプリリソース管理部、２０６ リソース枯渇判定部、２０７ Job管理部、２０８ 電源管理部、２０９ アプリケーション
【図１】
2018182378.tif 000003
【図２】
2018182378.tif 000004
【図３】
2018182378.tif 000005
【図４】
2018182378.tif 000006
【図５】
2018182378.tif 000007
【図６】
2018182378.tif 000008
【図７】
2018182378.tif 000009
【図８】
2018182378.tif 000010
【図９】
2018182378.tif 000011
【図１０】
2018182378.tif 000012
【図１１】
2018182378.tif 000013
【図１２】
2018182378.tif 000014
【図１３】
2018182378.tif 000015
【図１４】
2018182378.tif 000016
【図１５】
2018182378.tif 000017