JP6223001B2 - 画像処理装置、その制御方法、及びプログラム - Google Patents

Description

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

現在のＭｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ（ＭＦＰ）は、ドキュメントのコピーやスキャン、印刷といったＭＦＰに組み込まれた機能以外のアプリケーションを実行する機能を有するものが増えている。多くのＭＦＰではアプリケーション実行環境としてＪａｖａの実行環境を有し、Ｊａｖａ（登録商標）で記述されたアプリケーションを実行することができる。アプリケーション実行環境の例としてはキヤノン（登録商標）のＭＥＡＰ（登録商標）等があげられる。

一方、ＰＣ上のＪａｖａアプリケーションの場合は１アプリ１プロセスでアプリケーションを実行するが、ＭＦＰではＣＰＵやメモリの制限のためＯＳＧｉフレームワークなどを使用して１つのＪａｖａのプロセスで複数のアプリケーションを実行するものが多い。そのためＭＦＰ上で実行しているアプリケーションの１つにバグがありメモリリークを起こすと、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒが発生し全てのアプリケーションが停止してしまう可能性がある。また、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒはアプリケーションがメモリを要求したときに割り当てられるメモリが無かった場合に発生するため、問題のないアプリケーションの実行中に発生することがある。そのためメモリリークを起こしているアプリケーションを特定することは困難であった。

特許文献１には、スレッド毎にメモリを計測する技術が提案されている。しかし、後述する図１３に示すように１つのスレッドが複数のアプリケーションのコードを実行するような場合にはアプリケーション毎の使用メモリを計測することができなかった。

現行では、メモリリークを発見するために次の２つの方法が考えられる。一つはプロファイラというツールを使用しアプリケーションが生成したオブジェクトの状態を監視する方法である。もう一つはＪａｖａＶＭの使用するヒープメモリの内容をダンプし（以下では、ヒープダンプと称する。）アプリが生成したオブジェクトを解析する方法である。

このうちプロファイラを使用してオブジェクトの状態を監視する場合、アプリケーションの実行速度が極端に低下するためＣＰＵやメモリの制限が大きいＭＦＰへの適用は困難である。そのため、ヒープダンプを実行しアプリが生成したオブジェクトを解析する手法が用いられてきた。同様に、アプリケーション実行環境として使用可能なディスク容量が予め決められている場合がある。ディスク・フルの場合は、メモリリークと異なり、ＭＦＰを再起動しても自動的に復旧することがない。そのため、非特許文献１には、アプリケーションが予め使用量を宣言し、それを超えないようにインストール制限を行う技術が公開されている。

特開２００５−２６９４３９号公報

キヤノン、"ｉＲ−ＡＤＶ マニュアル"、「アプリケーションのインストール」ページ、「アプリケーションを使用できる状態にする」ページ、［online］、［平成２５年５月１７日検索］、インターネット＜ＵＲＬ：http://cweb.canon.jp/manual/ir-adv/＞

しかしながら、上記従来技術には以下に記載する問題がある。従来のヒープダンプでは取得したヒープダンプ情報をデバイスから取り出して解析することによりメモリリークを起こしているアプリケーションを見つけ、アプリケーションの使用するメモリ量を集計している。そのためリアルタイムで個々のアプリケーションのメモリ使用量を知ることはできない。一方、プロファイラでは、アプリケーションの実行速度が極端に低下するため、現実的にリアルタイムで個々のアプリケーションの使用するメモリ量を計測することは困難であった。

また、アプリケーションが予めディスク使用量を宣言し、それを超えないようにインストール制限を行う場合であっても、ＭＦＰ上で実行しているアプリケーションの１つにバグがあり、アプリケーション実行環境全体がディスク・フルになる可能性がある。その場合、バグのないアプリケーションでも、書き込みエラーが発生し、正常に動作を継続できなくなる可能性がある。

本発明は、上述の問題に鑑みて成されたものであり、パフォーマンスを維持したまま個々のアプリケーションで使用されるメモリ使用量又はディスク使用量をリアルタイムで計測する仕組みを提供することを目的とする。

本発明は、少なくとも、アプリケーション制御部と、システム制御部を有する画像処理装置であって、前記アプリケーション制御部は、アプリケーションの起動要求に応じて、該アプリケーションのクラスのクラスファイルを読み込み、当該クラスをロードさせる制御手段を有し、前記システム制御部は、
前記クラスをロードして、生成するオブジェクトに使用するメモリを確保し、スレッドに記録されたアプリケーション情報を前記確保したメモリに記録するとともに、当該オブジェクトを生成するオブジェクト生成手段を有し、前記アプリケーション制御部は、さらに、起動要求を受けたアプリケーションと前記アプリケーションを起動することによって使用したメモリとを、アプリケーション毎に紐付けて管理するメモリ管理手段を有し、前記システム制御部は、複数のアプリケーションを一つのアプリケーションとして扱い、
前記オブジェクト生成手段により生成されたオブジェクトが複数ある場合は、オブジェクト毎に、メモリを使用しているアプリケーションを関連付けることを特徴とする。

また、本発明は、少なくとも、アプリケーション制御部と、システム制御部を有する画像処理装置であって、前記アプリケーション制御部は、アプリケーションの起動要求に応じて、該アプリケーションのクラスのクラスファイルを読み込み、当該クラスをロードさせる制御手段を有し、前記システム制御部は、前記クラスをロードして、生成するオブジェクトに使用するファイルサイズを確保し、スレッドに記録されたアプリケーション情報を前記確保したファイルサイズをディスク使用量として記録するとともに、当該オブジェクトを生成するオブジェクト生成手段を有し、前記アプリケーション制御部は、さらに、起動要求を受けたアプリケーションと前記アプリケーションを起動することによって使用したディスクとを、アプリケーション毎に紐付けて管理するディスク管理手段を有し、前記システム制御部は、複数のアプリケーションを一つのアプリケーションとして扱い、前記オブジェクト生成手段により生成されたオブジェクトが複数ある場合は、オブジェクト毎に、メモリを使用しているアプリケーションを関連付けることを特徴とする。

本発明は、パフォーマンスを維持したまま個々のアプリケーションで使用されるメモリ使用量又はディスク使用量をリアルタイムで計測する仕組みを提供できる。

アプリケーション管理装置の構成を示す図。 アプリケーション管理装置のソフトウェア構成を示す図。 アプリケーション管理装置のモジュール構成を示す図。 マニフェストファイル。 アプリ用クラスローダテーブル、使用メモリテーブル。 クラスロード処理のフローチャート。 ＴＡＳＫＩＮＦＯクラスのメソッドが追加されたコードの例を示す図。 第１の実施形態のスレッド構造体の図。 第１の実施形態のＴＡＳＫＩＮＦＯ命令が挿入されたメソッドの実行時のフローチャート。 オブジェクトの構造体、及びヒープメモリを示す図。 第１の実施形態のオブジェクト生成処理を示すフローチャート。 ＧＣ処理のフローチャート。 複数のアプリケーション間での呼び出し処理の例を示す図。 第２の実施形態のスレッド構造体図。 第２の実施形態のＴＡＳＫＩＮＦＯ命令が挿入されたメソッドの実行時のフローチャート。 第２の実施形態のオブジェクト生成処理を示すフローチャート。 第３の実施形態のアプリケーション管理装置の構成を示す図。 使用メモリ量宣言テーブル。 第３の実施形態のオブジェクト生成処理を示すフローチャート。 第４の実施形態のアプリケーション管理装置の構成を示す図。 使用ディスク・テーブル２００２及び使用ディスク量宣言テーブル２００３の構成を示す図。 第４の実施形態のマニフェストファイルを示す図。 第４の実施形態の起動時のフローチャート。 ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクト生成時のフローチャート。 ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクトのｗｒｉｔｅメソッド実行時のフローチャート。 ＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅオブジェクトのｓｅｔＬｅｎｇｔｈメソッド実行時のフローチャート。 ＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅオブジェクトのｗｒｉｔｅメソッド実行時のフローチャート。 Ｆｉｌｅオブジェクトのｄｅｌｅｔｅメソッド実行時のフローチャート。

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

＜第１の実施形態＞
＜アプリケーション管理装置の構成＞
以下では、図１乃至図１２を参照して、本発明の第１の実施形態について説明する。まず、図１を参照して、アプリケーション管理装置１００のハードウェア構成について説明する。アプリケーション管理装置１００は、画像処理装置の一例である。アプリケーション管理装置１００は、制御部１２０、スキャナ１１１、プリンタ１１２、及び操作パネル１１３を備え、さらに、着脱可能なＩＣカードリーダ１１６を備える。制御部１２０は、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、外部記憶装置１０４、ＵＳＢＨ Ｉ／Ｆ制御部１０５、スキャナＩ／Ｆ制御部１０６、プリンタＩ／Ｆ制御部１０７、ＮＶＲＡＭ１０８、パネル制御部１０９、及びネットワークＩ／Ｆ制御部１１０を備える。

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

ＵＳＢＨ Ｉ／Ｆ制御部１０５はＵＳＢホストインタフェースを制御するためのものであり、さまざまなＵＳＢデバイスとの通信を制御する。スキャナＩ／Ｆ制御部１０６は、スキャナ１１１を制御する装置である。プリンタＩ／Ｆ制御部１０７は、プリンタ１１２を制御する装置である。ＮＶＲＡＭ１０８は、不揮発性のメモリであり、アプリケーション管理装置１００の各種設定値が保存される。

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

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

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

＜モジュール構成＞
次に、図３を参照して、本発明のアプリケーション管理装置１００のソフトウェア２００を構成するモジュールの一例について説明する。ＪａｖａＶＭ２０４は、バイトコード実行部３０１、メモリ管理部３０２、ヒープメモリ３０５、及びシステムクラスローダ３０６を備える。

バイトコード実行部３０１は、Ｊａｖａのプログラムコードであるバイトコードを解釈、実行する。ヒープメモリ３０５は、ＪａｖａＶＭ２０４が管理するメモリ領域であり、Ｊａｖａプログラムの実行によって生成されたＪａｖａオブジェクトを保持する。メモリ管理部３０２は、アプリケーションの使用するメモリの管理を行う。メモリ管理部３０２は、オブジェクト生成部３０３、及びＧＣ実行部３０４から構成される。オブジェクト生成部３０３は、バイトコード実行部３０１で実行されるプログラムコードの指示に従いＪａｖａのオブジェクトを生成する。ＧＣ実行部３０４は、ヒープメモリ３０５に保存されているＪａｖａオブジェクトのうち使用されなくなったものを削除するガーベージコレクションを実行する。システムクラスローダ３０６は、ＪａｖａＶＭ２０４の管理するクラスのロードを行う。通常、Ｊａｖａクラスは、必要になったとき、即ち、処理を実行する際に初めてクラスローダによってロードされる。

アプリケーションプラットフォーム２０５は、アプリケーション管理部３０８、アプリケーションメモリ管理部３０７、及びアプリ用クラスローダ管理部３０９から構成される。アプリケーションメモリ管理部３０７は、アプリ毎の使用メモリを管理する使用メモリテーブル３１３を有し、アプリケーション毎に使用するメモリを管理する。アプリケーション管理部３０８は、アプリケーションのインストール、起動、停止、アンインストール等のアプリケーションのライフサイクルを管理する。アプリ用クラスローダ管理部３０９は、アプリ用クラスローダテーブル３１０を有し、アプリケーション毎のアプリ用クラスローダの生成及び管理を行う。アプリ用クラスローダは、外部記憶装置１０４に保存されているアプリケーションのプログラムファイル３１２からクラスのロードを行う。

＜マニフェストファイル＞
次に、図４を参照して、アプリケーションのマニフェストファイルの内容について説明する。マニフェストファイルとは、アプリケーションのＪａｒファイルに含まれるファイルである。当該マニフェストファイルには、次のような情報が記述されている。

Ｂｕｎｄｌｅ−Ｎａｍｅ４０１は、アプリケーションの名称である。Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ４０２は、アプリケーションＩＤであり、アプリケーションを識別するためのユニークな識別子である。ＭａｘｉｍｕｍＭｅｍｏｒｙＵｓａｇｅ４０３は、アプリケーションが使用可能な最大メモリ使用量である。これらの設定項目はアプリケーションプラットフォーム２０５によって規定される。なお、上記設定項目及び設定値は一例であり、本発明を限定する意図はなく、上記項目以外や設定値以外にも様々な設定項目や設定値がマニフェストに記述されていてもよい。

＜テーブル＞
次に、図５を参照して、アプリケーションプラットフォーム２０５が管理するアプリ用クラスローダテーブル３１０及び使用メモリテーブル３１３について説明する。アプリ用クラスローダテーブル３１０は、アプリケーションの識別子であるアプリケーションＩＤ５０１とそのアプリ用クラスローダ５０２とが紐付けられて管理されるテーブルである。使用メモリテーブル３１３は、アプリケーションの識別子であるアプリＩＤ５０３と、そのアプリケーションが現在使用しているメモリ量５０４とが紐付けられて管理されるテーブルである。

＜ロード処理＞
次に、図６を参照して、本実施形態における、アプリケーションプラットフォーム２０５がアプリケーションのクラスをロードする際の処理手順について説明する。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。

アプリケーションの起動要求が実行されると、ＣＰＵ１０１は、アプリ用クラスローダ管理部３０９に対してアプリ用クラスローダの要求を行う。Ｓ６０２において、アプリ用クラスローダ管理部３０９は、アプリ用クラスローダの取得を開始する。まず、Ｓ６０３において、アプリ用クラスローダ管理部３０９は、アプリ用クラスローダテーブル３１０にクラスローダの要求を行ったアプリケーションのアプリＩＤに対応するクラスローダが存在するか否かを判定する。存在すればＳ６０７に遷移し、存在しなければＳ６０４に遷移する。

Ｓ６０４において、アプリ用クラスローダ管理部３０９は、アプリ用のクラスローダを生成する。続いて、Ｓ６０５において、アプリ用クラスローダ管理部３０９は、Ｓ６０４で生成したアプリ用クラスローダにアプリＩＤを保存する。さらに、Ｓ６０６において、アプリ用クラスローダ管理部３０９は、アプリ用クラスローダテーブル３１０にクラスローダの要求を行ったアプリケーションのアプリＩＤとＳ６０４で生成したアプリ用クラスローダを登録する。その後、Ｓ６０７に遷移してアプリケーションに処理を戻す。

Ｓ６０３でクラスローダありと判定した場合又はＳ６０６の処理の後に、Ｓ６０７において、ＣＰＵ１０１は、アプリ用クラスローダ管理部３０９から取得したアプリ用クラスローダを使用してアプリケーション２０６の起動を開始する。続いて、起動されたアプリケーション２０６は、Ｓ６０８においてアプリケーションオブジェクトの生成を開始する。さらに、アプリケーション２０６は、Ｓ６０９でアプリケーションのクラスをロードするため、アプリ用クラスローダ管理部３０９から取得したアプリ用クラスローダに対してアプリケーションクラスのクラスロード要求を行う。

Ｓ６１０において、アプリケーション用クラスローダは、アプリケーション２０６からアプリクラスのロード要求を受け付けると、まずＪａｖａＶＭに組み込まれているシステムクラスローダ３０６に対してクラスのロードを依頼する。Ｓ６１１において、システムクラスローダ３０６は、クラスロード要求があると、要求のあったクラスのクラスファイルのバイトコードを読み込む。続いて、Ｓ６１２において、システムクラスローダ３０６は、クラスファイルの読み込みができたか否かを判定し、できていればＳ６１３に遷移する。一方、できていなければアプリケーション固有のクラスのロードであるのでアプリ用クラスローダに処理を返しＳ６１４に遷移する。Ｓ６１３において、システムクラスローダ３０６は、Ｓ６１１で読み込んだバイトコードからクラスをロードし、Ｓ６１９に遷移してアプリケーション２０６にクラスオブジェクトを返す。

一方、Ｓ６１４において、アプリ用クラスローダは、アプリのＪａｒファイル３１２から要求されたクラスのバイトコードを読み込む。続いて、Ｓ６１５において、アプリ用クラスローダは、クラスファイルが存在して読み込みに成功したか否かを判定し、成功していればＳ６１６に遷移し、読み込めなかった場合はＳ６１８に遷移する。

Ｓ６１６において、アプリ用クラスローダは、読み込んだバイトコードにＴＡＳＫＩＮＦＯ命令を挿入し、Ｓ６１７において、ＴＡＳＫＩＮＦＯ命令を挿入したバイトコードからクラスをロードする。ＴＡＳＫＩＮＦＯ命令の詳細については図７を用いて後述する。その後、Ｓ６１９に遷移し、アプリケーション２０６にクラスオブジェクトを返す。

一方、Ｓ６１５でクラスファイルがないと判定した場合は、Ｓ６１８において、アプリケーション２０６は、ＣｌａｓｓＮｏｔＦｏｕｎｄＥｘｃｅｐｔｉｏｎ例外を発生させ、アプリの起動を終了する。Ｓ６１９においては、アプリケーション２０６は、Ｓ６１７でロードしたクラスを使ってアプリケーションオブジェクトのインスタンスを生成し、アプリの起動を終了する。

＜ＴＡＳＫＩＮＦＯ命令＞
次に、図７を参照して、本発明におけるＳ６１６でバイトコードに挿入されるＴＡＳＫＩＮＦＯ命令について説明する。７０１は、ＴＡＳＫＩＮＦＯ命令が挿入される前のコードである。７０２は、ＴＡＳＫＩＮＦＯ命令が挿入されたコードである。

７０３に示すように、メソッドの最初に「ＴＡＳＫＩＮＦＯ．ｓｅｔ（アプリケーションＩＤ）；」を挿入する。ここでは、アプリケーションＩＤを一例として”１１−１１１１−１１１１”としている。アプリケーションＩＤはＳ６０５でクラスローダに保存した値が文字列として挿入される。さらに、７０４に示すように、メソッドの最後に「ＴＡＳＫＩＮＦＯ．ｒｅｍｏｖｅ（）；」が挿入される。上記ＴＡＳＫＩＮＦＯ．ｓｅｔ（）メソッドとＴＡＳＫＩＮＦＯ．ｒｅｍｏｖｅ（）メソッドの詳細については後述する。

＜スレッド構造体＞
次に、図８を参照して、本発明の第１の実施形態におけるスレッドの構造体について説明する。スレッドの構造体８０１はアプリケーションＩＤを記憶するフィールド８０２を有する。フィールド８０２は、上記ＴＡＳＫＩＮＦＯ．ｓｅｔ（）メソッドとＴＡＳＫＩＮＦＯ．ｒｅｍｏｖｅ（）メソッドによって使用される。具体的には、ＴＡＳＫＩＮＦＯ．ｓｅｔ（）メソッドによってアプリケーションＩＤが設定され、ＴＡＳＫＩＮＦＯ．ｒｅｍｏｖｅ（）メソッドによって設定されているアプリケーションＩＤが消去される。

＜メソッドの処理＞
次に、図９を参照して、本発明におけるバイトコード実行部３０１においてアプリケーションのプログラムに含まれるＴＡＳＫＩＮＦＯ命令が挿入されたメソッドが実行された際の処理手順について説明する。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。

アプリケーションの該当メソッドの実行が開始されると、アプリケーション２０６は、メソッドの先頭にある「ＴＡＳＫＩＮＦＯ．ｓｅｔ（アプリケーションＩＤ）」を呼び出す。この際、引数としてアプリケーションＩＤを付加する。その後、ＴＡＳＫＩＮＦＯクラスのｓｅｔメソッドに処理が移行する。

Ｓ９０３において、ＴＡＳＫＩＮＦＯクラスのｓｅｔメソッドは、まず処理を実行しているカレントのスレッドを取得する。続いて、ｓｅｔメソッドは、Ｓ９０４で取得したスレッド構造体のアプリケーションＩＤのフィールド８０２にｓｅｔメソッドの引数として渡されたアプリケーションＩＤの値を保存し、アプリケーション２０６に処理を返す。

Ｓ９０５において、アプリケーション２０６は、アプリのメソッド内の処理を実行し、Ｓ９０６で、メソッドの末尾にある「ＴＡＳＫＩＮＦＯ．ｒｅｍｏｖｅ（）；」を呼び出す。その後、ＴＡＳＫＩＮＦＯクラスのｒｅｍｏｖｅメソッドに処理が移行する。

Ｓ９０７において、ＴＡＳＫＩＮＦＯクラスのｒｅｍｏｖｅメソッドは、まず処理を実行しているカレントのスレッドを取得する。Ｓ９０８において、ｒｅｍｏｖｅメソッドは、Ｓ９０７で取得したスレッドのスレッド構造体のフィールド８０２に設定されているアプリケーションＩＤの値を消去し、アプリケーションに処理を返す。アプリケーションはメソッドの処理を終了する。これにより、メソッドの実行中においては、スレッドに対応するアプリケーション情報が記録されていることとなる。この情報を用いて本実施形態に係る画像処理装置は、リアルタイムでメモリ使用量を把握することができる。

＜オブジェクト構造体及びヒープメモリ＞
次に、図１０を参照して、本発明のオブジェクトの構造体、及びヒープメモリについて説明する。１００１は、比較例となるＪａｖａＶＭのヒープメモリを示す。本実施形態に係るオブジェクトの構造体１００２は、ヒープメモリ１００１とは異なり、オブジェクト固有の情報に加えて、さらに、アプリケーションＩＤ（アプリケーション情報）を保存するフィールド１００３を備える。そのため、本実施形態におけるのＪａｖａＶＭ２０４のヒープメモリ３０５は１００４に示すようになる。例えば、ヒープメモリ３０５は、図１０に示すように、オブジェクトＡ乃至Ｅの構造体の領域を確保する。確保された領域には、それぞれ構造体におけるアプリケーションＩＤを保存する領域も設けられる。したがって、任意のオブジェクトがいずれのアプリケーションによるものであるかを容易に確認することができる。図１０では、使用されていないメモリ領域を、空きメモリとして表す。

＜オブジェクト生成処理＞
次に、図１１を参照して、第１の実施形態におけるオブジェクト生成処理の処理手順について説明する。オブジェクト生成処理は、上述した図９のＳ９０５の処理の中で実行される。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。

オブジェクト生成を行うアプリケーションのコードがバイトコード実行部３０１で実行されるとオブジェクト生成処理が開始され、ＪａｖａＶＭ２０４のオブジェクト生成部３０３が呼び出される。Ｓ１１０２において、オブジェクト生成部３０３は、まずカレントスレッドを取得する。続いて、Ｓ１１０３において、オブジェクト生成部３０３は、Ｓ１１０２で取得したスレッドの構造体のアプリケーションＩＤのフィールド８０２を読み取り、アプリケーションＩＤを取得する。

Ｓ１１０４において、オブジェクト生成部３０３は、オブジェクト生成用のメモリを取得してオブジェクトを生成する。さらに、Ｓ１１０５において、オブジェクト生成部３０３は、オブジェクトの構造体のアプリケーションＩＤのフィールド１００３にＳ１１０３で取得したアプリケーションＩＤを記録する。Ｓ１１０６において、オブジェクト生成部３０３は、メモリ増加量を記録するために、Ｓ１１０５で取得したアプリケーションＩＤと、Ｓ１１０４で生成したオブジェクトのサイズを引数として、アプリケーションメモリ管理部３０７を呼び出す。

Ｓ１１０７において、アプリケーションメモリ管理部３０７は、使用メモリテーブル３１３のアプリケーションＩＤのフィールド５０３をＳ１１０６で引数として指定されたアプリケーションＩＤで検索する。ここで、アプリケーションＩＤが存在すればＳ１１０９に遷移し、存在しなければＳ１１０８に遷移する。

Ｓ１１０８において、アプリケーション管理部３０８は、使用メモリサイズを０の新たなレコードを生成し、使用メモリテーブル３１３に登録しＳ１１０９に遷移する。Ｓ１１０９において、アプリケーション管理部３０８は、使用メモリテーブル３１３のアプリケーションＩＤに対応する使用メモリの値５０４を更新し、オブジェクト生成部３０３に処理を返す。Ｓ１１０において、オブジェクト生成部３０３は、生成したオブジェクトをアプリケーションに返す。アプリケーション２０６は、生成したオブジェクトを受け取り、オブジェクト生成処理を終了する。このように、本実施形態に係るアプリケーション管理装置は、オブジェクトを生成する際に、対応するアプリケーションＩＤと確保したメモリサイズとをアプリケーションメモリ管理部３０７によって管理する。

＜ＧＣ処理＞
次に、図１２を参照して、本発明の第１の実施形態におけるＧＣ処理の処理手順について説明する。ＪａｖａＶＭ２０４では、オブジェクトの生成に必要な空きメモリが不足すると不要になったオブジェクトを解放し空きメモリを増やす処理を行う。当該処理を、ガーベージコレクション（ＧＣ）という。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。

オブジェクト生成部３０３でのオブジェクト生成において空きメモリが不足するとＧＣ実行部３０４でＧＣ処理が開始される。Ｓ１２０２において、ＧＣ実行部３０４は、ヒープメモリ３０５からＧＣ対象である、だれからも参照されていないオブジェクトを検索する。Ｓ１２０３において、ＧＣ実行部３０４は、対象のオブジェクトが検索されたか否かを判定する。ここで、対象オブジェクトが存在すればＳ１２０４に遷移し、存在しなければＳ１２０９に遷移してＧＣ処理を終了する。

Ｓ１２０４において、ＧＣ実行部３０４は、ヒープメモリ３０５から対象オブジェクトの内容を取得する。続いて、ＧＣ実行部３０４は、Ｓ１２０４で取得したオブジェクトのアプリケーションＩＤフィールドの値を取得する。さらに、Ｓ１２０６において、ＧＣ実行部３０４は、メモリ減少量記録を行うために、Ｓ１２０５で取得したアプリケーションＩＤと、Ｓ１２０４で取得したオブジェクトのサイズとを引数として、アプリケーションメモリ管理部３０７を呼び出す。

Ｓ１２０７において、アプリケーションメモリ管理部３０７は、Ｓ１２０６の引数であるアプリケーションＩＤに対応する使用メモリテーブル３１３の使用メモリの値５０４を更新し、オブジェクト生成部３０３に処理を返す。アプリケーションメモリ管理部３０７から処理が戻ると、Ｓ１２０８において、ＧＣ実行部３０４は、オブジェクトを開放し、次のＧＣ対象オブジェクトを見つけるためにＳ１２０２に遷移する。

以上説明したように、本実施形態に係る画像処理装置は、アプリケーションの起動要求に応じて、当該アプリケーションのクラスのクラスファイルを読み込み、アプリケーションを示すアプリケーション情報をスレッドに記録するコードを、読み込んだクラスファイルに含まれるメソッドの最初に追加して、当該クラスをロードさせる。さらに、本画像処理装置は、メソッドの実行中に、生成するオブジェクトに使用するメモリを確保し、スレッドに記録されたアプリケーション情報を確保したメモリに記録するとともに、当該オブジェクトを生成し、生成したオブジェクトのアプリケーション情報とメモリサイズとを紐付けて管理する。これにより、本画像処理装置は、パフォーマンスを維持したまま個々のアプリケーションで使用されるメモリ使用量又はディスク使用量をリアルタイムで計測することができる。

＜第２の実施形態＞
以下では、図１３乃至図１６を参照して、本発明の第２の実施形態について説明する。なお、以下では、上記第１の実施形態と同様の構成及び制御については説明を省略する。クラスのロード処理については上記第１の実施形態と同様に実行する。まず、図１３を参照して、アプリケーションプラットフォーム２０５上で複数のアプリが連携して動作するシーケンスについて説明する。

ブラウザ１３０１は、本発明の画像処理装置であるアプリケーション管理装置１００と、ネットワークで接続されたデバイスで動作している。デバイスは、ＰＣやスマートフォン、タブレット端末である。ＨＴＴＰサーバアプリ１３０２は、アプリケーションプラットフォーム２０５上で動作するＨＴＴＰサーバプログラムであり、アプリケーションＩＤ「４４−４４４４−４４４４」を有している。Ｓｅｒｖｌｅｔアプリ１３０３は、ＨＴＴＰサーバアプリ１３０２と連携して動作するＳｅｒｖｌｅｔタイプのアプリケーションであり、アプリケーションＩＤ「１１−１１１１−１１１１４」を有している。

Ｓ１３０４において、ブラウザ１３０１は、ネットワークを通じてＨＴＴＰサーバアプリ１３０２に対してＨＴＴＰリクエストを送信する。続いて、Ｓ１３０５において、ＨＴＴＰサーバアプリ１３０２は、ＨＴＴＰリクエストを受信すると、ＨＴＴＰリクエストレスポンス処理を行うスレッドを１つ生成し、ＨＴＴＰリクエストの解析処理を行う。

ＨＴＴＰリクエストがＳｅｒｖｌｅｔアプリ１３０３に対するものであれば、Ｓ１３０６において、ＨＴＴＰサーバアプリ１３０２は、ＨＴＴＰリクエストの情報をつけて、Ｓｅｒｖｌｅｔアプリ１３０３を呼び出す。Ｓ１３０７において、Ｓｅｒｖｌｅｔアプリ１３０３は、Ｓｅｒｖｌｅｔで実装された固有の処理を行い、ＨＴＴＰサーバアプリ１３０２にＳｅｒｖｌｅｔの処理結果を返す。

Ｓ１３０９において、ＨＴＴＰサーバアプリ１３０２は、受け取ったＳｅｒｖｌｅｔの処理結果からＨＴＴＰレスポンスを生成し、Ｓ１３１０でネットワークを通じてブラウザにＨＴＴＰレスポンスを返す。このとき、Ｓ１３０５乃至Ｓ１３０９までは一つのスレッドで処理される。

アプリケーションプラットフォーム２０５上では図のように複数のアプリケーションが連携して動作するのは一般的である。オブジェクト生成は、ＨＴＴＰリクエスト処理（Ｓ１３０５）、Ｓｅｒｖｌｅｔ処理（Ｓ１３０７）、ＨＴＴＰレスポンス処理（Ｓ１３０９）のいずれか、または全てで行われる。よって、ＨＴＴＰサーバアプリ１３０２と、Ｓｅｒｖｌｅｔアプリ１３０３とのどちらでオブジェクトの生成が行われたかを判別する必要がある。

＜スレッド構造体＞
次に、図１４を参照して、本発明の第２の実施形態におけるスレッドの構造体について説明する。スレッド構造体１４０１は、フィールドとしてアプリケーションＩＤのスタック１４０２を有する。図１３の処理でＳｅｒｖｌｅｔ固有の処理であるＳ１３０７が実行されているときは、実行中のアプリケーションＩＤがスタックされている。この場合、アプリケーションＩＤのスタック１４０２には、上から順に、Ｓｅｒｖｌｅｔアプリ１３０３のアプリケーションＩＤ１４０３、ＨＴＴＰサーバアプリ１３０２のアプリケーションＩＤ１４０４がスタックされている。

＜メソッドの処理＞
次に、図１５を参照して、本発明の第２の実施形態におけるバイトコード実行部３０１においてアプリケーションのプログラムにふくまれるＴＡＳＫＩＮＦＯ命令が挿入されたメソッドが実行された際の処理について説明する。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。

アプリケーションの該当メソッドの実行が開始されると、アプリケーション２０６は、メソッドの先頭にある「ＴＡＳＫＩＮＦＯ．ｓｅｔ（アプリケーションＩＤ）；」７０３を呼び出し、ＴＡＳＫＩＮＦＯクラスのｓｅｔメソッドに処理が移行する。Ｓ９０３において、ＴＡＳＫＩＮＦＯクラスのｓｅｔメソッドは、まず処理を実行しているカレントのスレッドを取得する。続いて、Ｓ１５０１において、ｓｅｔメソッドは、取得したスレッド構造体のアプリケーションＩＤのスタック１４０２の先頭にｓｅｔメソッドの引数として渡されたアプリケーションＩＤの値を追加し、アプリケーションに処理を返す。

Ｓ９０５において、アプリケーション２０６は、アプリケーションのメソッド内の処理を実行し、メソッドの末尾にある「ＴＡＳＫＩＮＦＯ．ｒｅｍｏｖｅ（）；」７０４を呼び出し、ＴＡＳＫＩＮＦＯクラスのｒｅｍｏｖｅメソッドに処理が移行する。Ｓ９０７において、ＴＡＳＫＩＮＦＯクラスのｒｅｍｏｖｅメソッドは、まず処理を実行しているカレントのスレッドを取得する。続いて、Ｓ１５０２において、ｒｅｍｏｖｅメソッドは、Ｓ９０７で取得したスレッドのスレッド構造体のアプリケーションＩＤのスタックの先頭のアプリケーションＩＤを削除し、アプリケーションに処理を返す。その後、アプリケーション２０６はメソッドの処理を終了する。

＜オブジェクト生成処理＞
次に、図１６を参照して、本発明の第２の実施形態におけるオブジェクト生成処理について説明する。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。オブジェクト生成を行うアプリケーションのコードがバイトコード実行部３０１で実行されるとオブジェクト生成処理が開始され、ＪａｖａＶＭ２０４のオブジェクト生成部３０３が呼び出される。

Ｓ１１０２において、オブジェクト生成部３０３は、カレントスレッドを取得する。続いて、Ｓ１６０１において、オブジェクト生成部３０３は、Ｓ１１０２で取得したスレッドの構造体のアプリケーションＩＤのスタックの先頭のアプリケーションＩＤを取得する。

Ｓ１１０４において、オブジェクト生成部３０３は、オブジェクト生成用のメモリを取得してオブジェクトを生成する。続いて、Ｓ１１０５において、オブジェクト生成部３０３は、オブジェクトの構造体のアプリケーションＩＤのフィールド１００３に、Ｓ１６０１で取得したアプリケーションＩＤを記録する。さらに、Ｓ１１０６において、オブジェクト生成部３０３は、メモリ増加量を記録するために、Ｓ１１０５で取得したアプリケーションＩＤと、Ｓ１１０４で生成したオブジェクトのサイズとを引数として、アプリケーションメモリ管理部３０７を呼び出す。

Ｓ１１０７において、アプリケーション管理部３０８は、使用メモリテーブル３１３のアプリケーションＩＤのフィールド５０３をアプリケーションＩＤで検索し、存在するか否かを判定する。アプリケーションＩＤが存在すればＳ１１０９に遷移し、存在しなければＳ１１０８に遷移する。Ｓ１１０８において、アプリケーション管理部３０８は、使用メモリサイズが０の新たなレコードを生成し、使用メモリテーブル３１３に登録し、処理をＳ１１０９に遷移させる。Ｓ１１０９において、アプリケーション管理部３０８は、使用メモリテーブル３１３のアプリケーションＩＤに対応する使用メモリの値５０４を更新し、オブジェクト生成部３０３に処理を返す。

Ｓ１１１０において、オブジェクト生成部３０３は、生成したオブジェクトをアプリケーションに返す。アプリケーション２０６は、生成したオブジェクトを受け取り、オブジェクト生成処理を終了する。ＧＣ処理については、上記第１の実施形態と同様であるため説明を省略する。

以上説明したように、本実施形態によれば、複数のアプリケーションが連携して動作する場合には、スレッドに記録されるアプリケーション情報をスタック構造とする。これにより、図１３に示すようなケースにおいても、上記第１の実施形態と同様に、パフォーマンスを維持したまま個々のアプリケーションで使用されるメモリ使用量又はディスク使用量をリアルタイムで計測することができる。

＜第３の実施形態＞
以下では、図１７乃至図１９を参照して、本発明の第３の実施形態について説明する。なお、以下では、上記第１及び第２の実施形態と同様の構成及び制御については説明を省略する。まず、図１７を参照して、本実施形態のアプリケーション管理装置のソフトウェア２００におけるモジュールの構成例について説明する。

図１７に示すように、図３で説明した構成に加えて、アプリケーションメモリ管理部３０７は、使用メモリ量宣言テーブル１７０１を備える。クラスのロード処理については上記第１の実施形態と同様に実行する。ＴＡＳＫＩＮＦＯ命令が挿入されたメソッドの実行時処理については上記第１の実施形態と同様に実行する。

＜使用メモリ量宣言テーブル＞
次に、図１８を参照して、使用メモリ量宣言テーブル１７０１について説明する。使用メモリ量宣言テーブル１７０１は、アプリケーションＩＤ１８０１と、そのアプリケーションＩＤで識別されるアプリケーションが使用する最大のメモリ量を示す最大使用メモリ１８０２とを紐付けて管理するテーブルである。

アプリケーションの最大メモリ使用量は、図４で示されるアプリケーションのマニフェストファイルのＭａｘｉｍｕｍＭｅｍｏｒｙＵｓａｇｅ設定４０３に記述されている。アプリケーション管理部３０８は、アプリケーションがインストールされると、アプリケーションのＪａｒファイルからＡｐｐｌｉｃａｔｉｏｎ−Ｉｄ設定４０２と、ＭａｘｉｍｕｍＭｅｍｏｒｙＵｓａｇｅ設定４０３とを読み込む。さらに、アプリケーション管理部３０８は、読み込んだ値を使用メモリ量宣言テーブル１７０１に追加する。

＜オブジェクト生成処理＞
次に、図１９を参照して、本実施形態におけるオブジェクト生成処理の処理手順について説明する。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。

オブジェクト生成を行うアプリケーションのコードがバイトコード実行部３０１で実行されるとオブジェクト生成処理が開始され、ＪａｖａＶＭ２０４のオブジェクト生成部３０３が呼び出される。Ｓ１１０２において、オブジェクト生成部３０３は、まずカレントスレッドを取得する。続いて、Ｓ１６０１において、オブジェクト生成部３０３は、Ｓ１１０２で取得したスレッドの構造体のアプリケーションＩＤフィールド８０２を読み取り、アプリケーションＩＤを取得する。

Ｓ１１０４において、オブジェクト生成部３０３は、オブジェクト生成用のメモリを取得してオブジェクトを生成する。続いて、Ｓ１１０５において、オブジェクト生成部３０３は、オブジェクト構造体のアプリケーションＩＤのフィールド１００３にＳ１１０３で取得したアプリケーションＩＤを記録する。さらに、Ｓ１１０６において、オブジェクト生成部３０３は、メモリ増加量を記録するため、Ｓ１１０５で取得したアプリケーションＩＤと、Ｓ１１０４で生成したオブジェクトのサイズとを引数にアプリケーションメモリ管理部３０７を呼び出す。

Ｓ１１０７において、アプリケーションメモリ管理部３０７は、使用メモリテーブル３１３のアプリケーションＩＤのフィールド５０３をアプリケーションＩＤで検索し、存在するか否かを判定する。アプリケーションＩＤが存在すればＳ１９０１に遷移し、存在しなければＳ１１０８に遷移する。Ｓ１１０８において、アプリケーションメモリ管理部３０７は、使用メモリサイズが０の新たなレコードを生成し、使用メモリテーブル３１３に登録し、処理をＳ１９０１に遷移させる。

Ｓ１９０１において、アプリケーションメモリ管理部３０７は、使用メモリテーブル３１３のアプリケーションＩＤフィールド５０３をアプリケーションＩＤで検索し、現在の使用メモリサイズを取得する。存在しなければ新たなレコードを生成し現在の使用メモリサイズを０とする。

次に、Ｓ１９０２において、アプリケーションメモリ管理部３０７は、使用メモリ量宣言テーブル１７０１内をアプリケーションＩＤで検索し、アプリケーションＩＤに対応するアプリケーションの使用メモリ宣言量を取得する。Ｓ１９０３において、アプリケーションメモリ管理部３０７は、オブジェクト生成部３０３からＳ１１０６で渡されたオブジェクトサイズと、Ｓ１９０１の現在の使用メモリサイズとの合計が、Ｓ１９０２の最大メモリ使用量以下であるか否かを判定する。以下であれば、Ｓ１１０９に遷移する、超えていればＳ１９０４に遷移する。

Ｓ１１０９において、アプリケーションメモリ管理部３０７は、使用メモリテーブル３１３のアプリケーションＩＤに対応する使用メモリの値５０４を更新し、オブジェクト生成部３０３に処理を返す。Ｓ１１１０において、オブジェクト生成部３０３は、生成したオブジェクトをアプリケーションに返す。アプリケーションは、生成したオブジェクトを受け取りオブジェクト生成処理を終了する。

一方、Ｓ１９０３で超えていると判定すると、Ｓ１９０４において、アプリケーションメモリ管理部３０７は、メモリエラーを発生させる。続いて、Ｓ１９０５において、アプリケーションメモリ管理部３０７は、アプリケーション管理部３０８にアプリケーションＩＤに対応するアプリケーションの停止処理を依頼し、処理をアプリケーションに返す。アプリケーションは、オブジェクト生成処理を終了する。

以上説明したように、本実施形態によれば、上記第１の実施形態と上記第２の実施形態の少なくとも何れかの構成加えて、さらに、各アプリケーションにおけるメモリ最大使用量を定義したテーブルを備える。さらに、本画像処理装置は、オブジェクト生成時に確保するメモリサイズによって、現在既に使用しているメモリ使用量と、確保したメモリサイズとの合計が、上記メモリ最大使用量を超える場合には、当該オブジェクトの生成を中止するように制御することができる。

＜第４の実施形態＞
以下では、図２０乃至図２８を参照して、本発明の第４の実施形態について説明する。本実施形態では、上記第１乃至第３の実施形態の仕組みを使って、メモリと同様に外部記憶装置１０４のディスク使用量を制限する実施形態について説明する。したがって、本実施形態は、上記第１乃至第３の実施形態とそれぞれ組み合わせることが可能である。なお、以下では、上記第１乃至第３の実施形態と同様の構成及び制御については説明を省略する。クラスロード処理については、上記第１の実施形態と同様に実行する。ＴＡＳＫＩＮＦＯ命令が挿入されたメソッドの実行時処理については、上記第１の実施形態と同様に実行する。

本実施形態では、アプリケーション管理部３０８によってインストールされたアプリケーションは、外部記憶装置１０４の所定のディレクトリに格納される。また、アプリケーションは、アプリケーション自身がインストールされたディレクトリ下のみを使用できるように制限されているものとする。

＜モジュール構成＞
まず、図２０を参照して、本実施形態における、アプリケーション管理装置１００のソフトウェア２００におけるモジュールの構成例について説明する。図１７の構成に加え、アプリケーションプラットフォーム２０５がアプリケーション・ディスク管理部２００１を備え、ＪａｖａＶＭ２０４がファイル・アクセス管理部２００４を備える。

アプリケーション・ディスク管理部２００１は、後述の使用ディスク・テーブル２００２と使用ディスク量宣言テーブル２００３により構成される。ファイル・アクセス管理部２００４は、アクセス制御部２００５から構成され、アプリケーション２０６から外部記憶装置１０４へのファイル・アクセスを制御する。

＜使用ディスク・テーブル及び使用ディスク量宣言テーブル＞
図２１は、使用ディスク・テーブル２００２及び使用ディスク量宣言テーブル２００３の構成を示す。使用ディスク・テーブル２００２には、アプリケーションＩＤ２１０１と、そのアプリケーションが現在使用しているディスク使用量２１０２とが紐付けられて管理されている。使用ディスク量宣言テーブル２００３は、アプリケーションＩＤ２２０１と、そのアプリケーションが使用する最大使用量２２０２とが紐付けられて管理されている。使用ディスク・テーブル２００２と使用ディスク量宣言テーブル２００３とは、１つのテーブルで管理されていても良く、同等の情報が管理されるのであれば、本実施形態の構成に限定するものではない。

図２２は、本実施形態のアプリケーションのマニフェストファイルの内容である。図４で示す内容に加え、アプリケーションの最大ディスク使用量を示すＭａｘｉｍｕｍＦｉｌｅｓｐａｃｅＵｓａｇｅ２３０１が追加されている。なお、ここでは、ＭａｘｉｍｕｍＭｅｍｏｒｙＵｓａｇｅ設定４０３も含んでいるが、本発明はこれに限定されず、例えば、ＭａｘｉｍｕｍＦｉｌｅｓｐａｃｅＵｓａｇｅ２３０１のみ含むようにしてもよい。

＜初期化処理＞
次に、図２３を参照して、本実施形態のアプリケーションプラットフォーム２０５が起動されるときのアプリケーション管理部３０８の初期化処理について説明する。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。

アプリケーションプラットフォーム２０５が起動されると、Ｓ２４０１において、アプリケーション管理部３０８は、インストール済みのアプリケーションの数を取得する。Ｓ２４０２において、アプリケーション管理部３０８は、変数ｉ＝０として初期化し、Ｓ２４０３でアプリケーション数ｊと比較し、ｉ＜ｊであればＳ２４０４に遷移し、そうでなければ全てのアプリケーションについて後述する処理を行ったと判断し処理を終了する。Ｓ２４０４において、アプリケーション管理部３０８は、アプリケーションＩＤを取得し、Ｓ２４０５でアプリケーションが宣言しているディスク使用量を取得する。そして、アプリケーション・ディスク管理部２００１を呼び出す。

Ｓ２４０６において、アプリケーション・ディスク管理部２００１は、使用ディスク量宣言テーブルに該当するアプリケーションＩＤが登録済みか否かを判定し、未登録であればＳ２４０７でレコードを追加し、Ｓ２４０８に遷移する。一方、登録されていればそのままＳ２４０８に進む。Ｓ２４０８において、アプリケーション・ディスク管理部２００１は、使用ディスク量宣言テーブル２００３にアプリケーションＩＤ２２０１と最大使用量２２０２のデータとを紐付けて追加し、処理をアプリケーション管理部３０８に返す。

次に、Ｓ２４０９において、アプリケーション管理部３０８は、アプリケーションがインストールされているフォルダ以下の容量を取得し、再度アプリケーション・ディスク管理部２００１を呼び出す。Ｓ２４１０において、使用ディスク・テーブルに該当するアプリケーションＩＤが登録済みか否かを判定し、未登録であればＳ２４１１でレコードを追加しＳ２４１２に遷移する。一方、登録されていればそのままＳ２４１２に進む。Ｓ２４１２において、アプリケーション・ディスク管理部２００１は、使用ディスク・テーブル２００２にアプリケーションＩＤ２１０１と使用量２１０２とのデータを紐付けて追加し、処理をアプリケーション管理部３０８に返す。Ｓ２４１３において、アプリケーション管理部３０８は、変数ｉをインクリメントしてＳ２４０３の判定に戻る。

なお、アプリケーション管理部３０８において、新たにアプリケーションをインストールした際、外部記憶装置１０４の所定のフォルダにアプリケーションをインストールする。その後、本フローチャートと同様の処理を行い、使用ディスク量宣言テーブル２００３、使用ディスク・テーブル２００２に情報を追加することは言うまでもない。さらに、アプリケーション管理部３０８において、アプリケーションのアンインストールする際、アプリケーションをインストールしたフォルダを削除する。それと同時に、使用ディスク量宣言テーブル２００３、使用ディスク・テーブル２００２から該当するアプリケーションの情報を削除することも言うまでもないことである。

本フローチャートの処理により、画像処理装置であるアプリケーション管理装置１００の起動時に、アプリケーション管理部３０８によって管理されているアプリケーションが使用している起動初期状態のディスク使用量を管理することが可能となる。

＜オブジェクト生成処理＞
図２４は、ファイルの生成、書き込みを行うためのＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクトが生成された際のフローチャートである。以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。ここでは、第１の実施形態で説明した図１１の制御と異なる部分について説明する。

Ｓ１１０３でアプリＩＤを取得すると、Ｓ２５０１において、オブジェクト生成部３０３は、生成するオブジェクトがＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍか否かを判定する。ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍの場合はＳ２５０２に進み、それ以外のオブジェクトの生成の場合は、Ｓ１１０４に進む。

Ｓ２５０２において、オブジェクト生成部３０３は、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクトを生成するための引数を取し、Ｓ２５０３において、取得した引数から操作対象のファイルサイズを取得する。続いて、Ｓ２５０４において、オブジェクト生成部３０３は、本来のＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクトの生成処理を呼び出す。続いて、Ｓ２５０５において、オブジェクト生成部３０３は、Ｓ２５０２で取得した引数、或いはオブジェクトの生成方法から、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクトが、Ａｐｐｅｎｄ Ｍｏｄｅで生成されているか否かを判定する。ＪａｖａにおけるＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクトの仕様は、Ａｐｐｅｎｄ Ｍｏｄｅの場合は既存のファイルの最終端にデータを書き足すように動作し、そうでなければファイルサイズを０に戻して書き換えるように動作する。判定の結果、Ａｐｐｅｎｄ Ｍｏｄｅの場合は、Ｓ１１１０に進む。

一方、Ａｐｐｅｎｄ Ｍｏｄｅでない場合は、操作対象のファイルサイズが０になると判断し、Ｓ２５０６に遷移する。Ｓ２５０６において、アプリケーション・ディスク管理部２００１は、使用ディスク・テーブル２００２の本アプリケーションの使用量２１０２から、Ｓ２５０３で取得したサイズを減算し、処理をオブジェクト生成部３０３に返しＳ１１１０に遷移する。

Ｓ１１１０において、オブジェクト生成部３０３は、アプリケーションに処理を返し、アプリケーションは、オブジェクト生成処理を終了する。

＜ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクトのｗｒｉｔｅメソッド＞
次に、図２５を参照して、アプリケーション２０６が、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクトのｗｒｉｔｅメソッドを呼び出したときの処理手順について説明する。以下で説明する処理は、図９、及び図１５のＳ９０５の処理の中で実行される。また、以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。実行に際し、バイトコード実行部３０１からファイル・アクセス管理部２００４のアクセス制御部２００５の処理を呼び出すものである。

Ｓ２６０１において、バイトコード実行部３０１は、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクトのｗｒｉｔｅメソッドか否かを判定する。ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍオブジェクトのｗｒｉｔｅメソッドであれば、Ｓ２６０２に進み、そうでなければＳ２６１１で他のメソッドの処理を呼び出して処理を終了する。

ｗｒｉｔｅメソッドの実行にあたり、Ｓ２６０２において、ファイル・アクセス管理部２００４は、カレントスレッドのスレッド構造体のアプリケーションＩＤフィールド８０２を読み取る。続いて、Ｓ２６０３において、ファイル・アクセス管理部２００４は、ｗｒｉｔｅメソッドに渡された書き込みデータのサイズ（＝ａ）を取得し、処理をアプリケーション・ディスク管理部２００１に渡す。

次に、Ｓ２６０４において、アプリケーション・ディスク管理部２００１は、Ｓ２６０２で取得したアプリケーションＩＤを使い、使用ディスク・テーブル２００２から当該アプリケーションの使用量２１０２（＝Ｘ）を取得する。さらに、Ｓ２６０５において、アプリケーション・ディスク管理部２００１は、使用ディスク量宣言テーブル２００３から最大使用量２２０２（＝Ｙ）を取得し、処理をファイル・アクセス管理部２００４に返す。

Ｓ２６０６において、ファイル・アクセス管理部２００４は、当該アプリケーションの使用量Ｘと書き込みデータサイズａを加算したサイズが、最大使用量Ｙを超えるか否かを判定する。最大使用量Ｙを超える場合はＳ２６０８に遷移し、ファイル・アクセス管理部２００４は、アプリケーション２０６が宣言する最大使用量２２０２を超える書き込みを行うと判断し、所定のエラー（ディスクエラー）を通知し、本処理を終了する。

最大使用量Ｙを超えない場合は、Ｓ２６０７に進み、ファイル・アクセス管理部２００４は、本来のｗｒｉｔｅメソッドを呼び出し、ファイルの書き込みを実行する。その後、Ｓ２６０９において、ファイル・アクセス管理部２００４は、ファイルの書き込みに失敗したか否かを判定し、失敗した場合は本処理を終了し、成功した場合は処理をアプリケーション・ディスク管理部２００１に渡し、Ｓ２６１０に遷移する。Ｓ２６１０において、アプリケーション・ディスク管理部２００１は、使用ディスク・テーブル２００２の当該アプリケーションの使用量２１０２に書き込みデータサイズ（＝ａ）を加算し、処理を終了する。

Ｊａｖａには、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍと類似するＦｉｌｅＷｒｉｔｅｒクラスが存在する。ＦｉｌｅＷｒｉｔｅクラスを使う場合であっても、ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍと同じ構成をとることで対応できるため本実施形態では説明を割愛する。

＜ＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅｍオブジェクトのｓｅｔＬｅｎｇｔｈメソッド＞
次に、図２６を参照して、アプリケーション２０６が、ＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅｍオブジェクトのｓｅｔＬｅｎｇｔｈメソッドを呼び出したときの処理手順について説明する。以下で説明する処理は、図９、及び図１５のＳ９０５の処理の中で実行される。また、以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。実行に際し、バイトコード実行部３０１からファイル・アクセス管理部２００４のアクセス制御部２００５の処理を呼び出すものである。ＪａｖａにおけるＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅｍオブジェクトのｓｅｔＬｅｎｇｔｈ仕様は、操作対象のファイルサイズをｓｅｔＬｅｎｇｔｈにより指定されたサイズに変更するように動作する。

Ｓ２７０１において、バイトコード実行部３０１は、ＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅｍオブジェクトのｓｅｔＬｅｎｇｔｈメソッドか否かを判定する。ＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅｍオブジェクトのｓｅｔＬｅｎｇｔｈメソッドであれば、Ｓ２７０２に遷移し、そうでなければＳ２７１６に遷移し他のメソッドの処理を呼び出して処理を終了する。

ｓｅｔＬｅｎｇｔｈメソッドの実行にあたり、Ｓ２７０２において、ファイル・アクセス管理部２００４は、カレントスレッドのスレッド構造体のアプリケーションＩＤフィールド８０２を読み取る。続いて、Ｓ２７０３において、ファイル・アクセス管理部２００４は、ｓｅｔＬｅｎｇｔｈメソッドの対象となるファイルのサイズ（＝ａ）を取得し、Ｓ２７０４でｓｅｔＬｅｎｇｔｈメソッドに指定されたサイズ（＝ｂ）を取得する。その後、Ｓ２７０５において、ファイル・アクセス管理部２００４は、ａとｂを比較し、ｂが大きい場合、すなわちファイルサイズが大きくなる場合はＳ２７０９に遷移する。そうでない場合はＳ２７０６に遷移し、本来のｓｅｔＬｅｎｔｇｈメソッドを呼び出して、Ｓ２７０７でｓｅｔＬｅｎｇｔｈメソッドの実行結果を判定し、成功した場合はＳ２７０８に遷移し、失敗した場合は処理を終了する。Ｓ２７０８において、アプリケーション・ディスク管理部２００１は、使用ディスク・テーブル２００２の当該アプリケーションの使用量２２０２からａ−ｂで求められる値を減算するし、処理を終了する。

一方、Ｓ２７０５でファイルサイズが大きくなると判定された場合、Ｓ２７０９において、アプリケーション・ディスク管理部２００１は、Ｓ２７０１で取得した当該アプリケーションＩＤのディスク使用量２１０２（＝Ｘ）を取得する。続いて、Ｓ２７１０において、アプリケーション・ディスク管理部２００１は、最大使用量２２０２（＝Ｙ）を取得する。その後、Ｓ２７１１において、ファイル・アクセス管理部２００４は、現在の使用量ＸにｓｅｔＬｅｎｇｔｈメソッドによる増加分が、最大使用量Ｙを超えるか否かを判定する（Ｘ＋（ｂ−ａ）＞Ｙ）。

最大使用量Ｙを超える場合はＳ２７１５に遷移し、ファイル・アクセス管理部２００４は、アプリケーション２０６が宣言する最大使用量２２０２を超える書き込みを行うと判断し、所定のエラーを通知し、本処理を終了する。一方、最大使用量Ｙを超えないと判断した場合はＳ２７１２に遷移し、ファイル・アクセス管理部２００４は、本来のｓｅｔＬｅｎｇｔｈメソッドを呼び出す。その後、Ｓ２７１３において、ファイル・アクセス管理部２００４は、ｓｅｔＬｅｎｇｔｈメソッドの実行結果を判定し、成功した場合はＳ２７１４に遷移する。Ｓ２７１４において、アプリケーション・ディスク管理部２００１は、使用ディスク・テーブル２００２の当該アプリケーションの使用量２２０２にｂ−ａで求められる値を加算し、処理を終了する。一方、Ｓ２７１２の判定でエラーと判断された場合は、本処理を終了する。

＜ＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅｍオブジェクトのｗｒｉｔｅメソッド＞
次に、図２７を参照して、アプリケーション２０６が、ＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅｍオブジェクトのｗｒｉｔｅメソッドを呼び出したときの処理手順について説明する。以下で説明する処理は、図９、及び図１５のＳ９０５の処理の中で実行される。また、以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。実行に際し、バイトコード実行部３０１からファイル・アクセス管理部２００４のアクセス制御部２００５の処理を呼び出すものである。ＪａｖａにおけるＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅｍオブジェクトのｗｒｉｔｅ仕様は、操作対象のファイルのファイルポインタの位置からデータを書き込むように動作する。その際、書き込みサイズがファイルサイズを超える場合はファイルサイズが増えるように動作する。

Ｓ２８０１において、バイトコード実行部３０１は、ＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅｍオブジェクトのｗｒｉｔｅメソッドか否かを判定する。ＲａｎｄｏｍＡｃｃｅｓｓＦｉｌｅｍオブジェクトのｗｒｉｔｅメソッドであれば、Ｓ２８０２に進み、そうでなければＳ２８１５で他のメソッドの処理を呼び出して処理を終了する。

ｗｒｉｔｅメソッドの実行にあたり、Ｓ２８０２において、ファイル・アクセス管理部２００４は、カレントスレッドのスレッド構造体のアプリケーションＩＤフィールド８０２を読み取る。続いて、Ｓ２８０３において、ファイル・アクセス管理部２００４は、ｗｒｉｔｅメソッドに渡された書き込みデータのサイズ（＝ａ）を取得し、Ｓ２８０４で現在のファイルポインタの位置（＝ｂ）を取得する。さらに、Ｓ２８０５で、ファイル・アクセス管理部２００４は、操作対象ファイルのサイズ（＝ｃ）を取得する。その後、Ｓ２８０６において、ファイル・アクセス管理部２００４は、書き込みサイズａと、ファイルポインタｂの位置を加算し、ファイルサイズが増えるか否かを判定する（ａ＋ｂ＞ｃ）。ファイルサイズが増える場合は、Ｓ２８０８へ遷移し、そうでなければ、Ｓ２８０７で本来のｗｒｉｔｅメソッドを呼び出し、ファイルサイズが変わらないため、本処理を終了する。

Ｓ２８０８において、アプリケーション・ディスク管理部２００１は、Ｓ２８０１で取得した当該アプリケーションＩＤのディスク使用量２１０２（＝Ｘ）を取得し、Ｓ２８０９で最大使用量２２０２（＝Ｙ）を取得し、Ｓ２８１０に遷移する。Ｓ２８１０において、ファイル・アクセス管理部２００４は、現在の使用量Ｘにｗｒｉｔｅメソッドによる増加分が、最大使用量Ｙを超えるか否かを判定する（（ａ＋ｂ）−ｃ＋Ｘ＞Ｙ）。最大使用量Ｙを超える場合はＳ２８１４に遷移し、ファイル・アクセス管理部２００４は、アプリケーション２０６が宣言する最大使用量２２０２を超える書き込みを行うと判断し、所定のエラーを通知し、本処理を終了する。

一方、最大使用量Ｙを超えないと判断した場合はＳ２８１１に遷移し、ファイル・アクセス管理部２００４は、本来のｗｒｉｔｅメソッドを呼び出す。その後、Ｓ２８１２において、ファイル・アクセス管理部２００４は、ｗｒｉｔｅメソッドの実行結果を判定する。成功した場合はＳ２８１３に遷移し、アプリケーション・ディスク管理部２００１は、使用ディスク・テーブル２００２の当該アプリケーションの使用量２２０２にａ＋ｂ−ｃで求められる値を加算し、処理を終了する。一方、Ｓ２８１１の判定でエラーと判断された場合は、本処理を終了する。

＜Ｆｉｌｅオブジェクトのｄｅｌｅｔｅメソッド＞
次に、図２８を参照して、アプリケーション２０６が、Ｆｉｌｅオブジェクトのｄｅｌｅｔｅメソッドを呼び出したときの処理手順について説明する。以下で説明する処理は、図９、及び図１５のＳ９０５の処理の中で実行される。また、以下で説明する処理は、ＣＰＵ１０１がＲＯＭ１０２や外部記憶装置１０４に記憶された制御プログラムをＲＡＭ１０３に読み出して実行することにより実現される。

Ｓ２９０１において、バイトコード実行部３０１は、Ｆｉｌｅオブジェクトのｄｅｌｅｔｅメソッドか否かを判定する。ＦｉｌｅオブジェクトのｄｅｌｅｔｅメソッドであればＳ２９０２に遷移し、そうでなければＳ２９０７に遷移し、他のメソッドの処理を呼び出して処理を終了する。

Ｓ２９０２において、ファイル・アクセス管理部２００４は、ｄｅｌｅｔｅメソッドの実行にあたり、カレントスレッドのスレッド構造体のアプリケーションＩＤフィールド８０２を読み取る。続いて、Ｓ２９０３において、ファイル・アクセス管理部２００４は、ｄｅｌｅｔｅメソッドの対象となるファイルのサイズ（＝ａ）を取得し、Ｓ２９０４で本来のｄｅｌｅｔｅメソッドを呼び出す。

Ｓ２９０５において、ファイル・アクセス管理部２００４は、ｄｅｌｅｔｅメソッドの実行結果を判定し、エラーと判断された場合は本処理を終了する。一方、成功した場合はＳ２９０６に遷移する。Ｓ２９０６において、アプリケーション・ディスク管理部２００１は、使用ディスク・テーブル２００２の当該アプリケーションの使用量２２０２から操作対象のファイルサイズａを減算し、処理を終了する。

なお、本実施形態では、アプリケーション２０６が宣言する最大使用サイズを超える場合に所定のエラーを通知（Ｓ２６０８，Ｓ２７１５，Ｓ２８１４）をしている。アプリケーション管理部３０８は、この通知を検知した場合、対応するアプリケーションを停止するように構成することも可能である。

以上説明したように、本実施形態に係る画像処理装置は、アプリケーションの起動要求に応じて、当該アプリケーションのクラスのクラスファイルを読み込み、アプリケーションを示すアプリケーション情報をスレッドに記録するコードを、読み込んだクラスファイルに含まれるメソッドの最初に追加して、当該クラスをロードさせる。さらに、本画像処理装置は、メソッドの実行中に、生成するオブジェクトに使用するファイルサイズを確保し、スレッドに記録されたアプリケーション情報を確保したファイルサイズをディスク使用量として記録するとともに、当該オブジェクトを生成し、生成したオブジェクトのアプリケーション情報とディスク使用量とを紐付けて管理する。これにより、本実施形態では、ディスク使用量に関しても、上記第１乃至第３の実施形態と同様の効果を得ることができる。

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

Claims (11)

1. 少なくとも、アプリケーション制御部と、システム制御部を有する画像処理装置であって、
   前記アプリケーション制御部は、
   アプリケーションの起動要求に応じて、該アプリケーションのクラスのクラスファイルを読み込み、当該クラスをロードさせる制御手段を有し、
   前記システム制御部は、
   前記クラスをロードして、生成するオブジェクトに使用するメモリを確保し、スレッドに記録されたアプリケーション情報を前記確保したメモリに記録するとともに、当該オブジェクトを生成するオブジェクト生成手段を有し、
   前記アプリケーション制御部は、さらに、
   起動要求を受けたアプリケーションと前記アプリケーションを起動することによって使用したメモリとを、アプリケーション毎に紐付けて管理するメモリ管理手段を有し、
   前記システム制御部は、複数のアプリケーションを一つのアプリケーションとして扱い、
   前記オブジェクト生成手段により生成されたオブジェクトが複数ある場合は、オブジェクト毎に、メモリを使用しているアプリケーションを関連付けることを特徴とする画像処理装置。
2. 前記制御手段は、さらに、前記スレッドに記録したアプリケーション情報を削除するコードを、前記読み込んだクラスファイルに含まれるメソッドの最後に追加することを特徴とする請求項１に記載の画像処理装置。
3. 複数のアプリケーションが連携して動作する場合には、前記スレッドに記録される前記アプリケーション情報は、スタック構造とすることを特徴とする請求項１又は２に記載の画像処理装置。
4. 前記アプリケーション情報と、当該アプリケーションが使用可能なメモリサイズを紐付けて定義したテーブルと、
   前記オブジェクト生成手段によってオブジェクトを生成するためのメモリが確保されたときに、前記メモリ管理手段で管理されている前記アプリケーション情報に対応するアプリケーションが使用しているメモリサイズと、前記確保されたメモリのサイズとの合計が対応する前記使用可能なメモリサイズを超えたか否かを判定する判定手段と、
   前記判定手段によって前記合計が前記使用可能なメモリサイズを超えたと判定されると、メモリエラーを生成する制限手段と
   をさらに備えることを特徴とする請求項１乃至３の何れか１項に記載の画像処理装置。
5. 少なくとも、アプリケーション制御部と、システム制御部を有する画像処理装置であって、
   前記アプリケーション制御部は、
   アプリケーションの起動要求に応じて、該アプリケーションのクラスのクラスファイルを読み込み、当該クラスをロードさせる制御手段を有し、
   前記システム制御部は、
   前記クラスをロードして、生成するオブジェクトに使用するファイルサイズを確保し、スレッドに記録されたアプリケーション情報を前記確保したファイルサイズをディスク使用量として記録するとともに、当該オブジェクトを生成するオブジェクト生成手段を有し、
   前記アプリケーション制御部は、さらに、
   起動要求を受けたアプリケーションと前記アプリケーションを起動することによって使用したディスクとを、アプリケーション毎に紐付けて管理するディスク管理手段を有し、
   前記システム制御部は、複数のアプリケーションを一つのアプリケーションとして扱い、
   前記オブジェクト生成手段により生成されたオブジェクトが複数ある場合は、オブジェクト毎に、メモリを使用しているアプリケーションを関連付けることを特徴とする画像処理装置。
6. 前記制御手段は、さらに、前記スレッドに記録したアプリケーション情報を削除するコードを、前記読み込んだクラスファイルに含まれるメソッドの最後に追加することを特徴とする請求項５に記載の画像処理装置。
7. 複数のアプリケーションが連携して動作する場合には、前記スレッドに記録される前記アプリケーション情報は、スタック構造とすることを特徴とする請求項５又は６に記載の画像処理装置。
8. 前記アプリケーション情報と、当該アプリケーションが使用可能なディスク使用量を紐付けて定義したテーブルと、
   前記オブジェクト生成手段によってオブジェクトを生成するためのファイルサイズが確保されたときに、前記ディスク管理手段で管理されている前記アプリケーション情報に対応するアプリケーションが使用しているディスク使用量と、前記確保されたファイルサイズとの合計が、対応する前記使用可能なディスク使用量を超えたか否かを判定する判定手段と、
   前記判定手段によって前記合計が前記使用可能なディスク使用量を超えたと判定されると、ディスクエラーを生成する制限手段と
   をさらに備えることを特徴とする請求項５乃至７の何れか１項に記載の画像処理装置。
9. 少なくとも、アプリケーション制御部と、システム制御部を有する画像処理装置の制御方法であって、
   前記アプリケーション制御部は、
   アプリケーションの起動要求に応じて、該アプリケーションのクラスのクラスファイルを読み込み、当該クラスをロードさせる制御工程を有し、
   前記システム制御部は、
   前記クラスをロードして、生成するオブジェクトに使用するメモリを確保し、スレッドに記録されたアプリケーション情報を前記確保したメモリに記録するとともに、当該オブジェクトを生成するオブジェクト生成工程を有し、
   前記アプリケーション制御部は、さらに、
   起動要求を受けたアプリケーションと前記アプリケーションを起動することによって使用したメモリとを、アプリケーション毎に紐付けて管理するメモリ管理工程を有し、
   前記システム制御部は、複数のアプリケーションを一つのアプリケーションとして扱い、
   前記オブジェクト生成工程で生成されたオブジェクトが複数ある場合は、オブジェクト毎に、メモリを使用しているアプリケーションを関連付けることを特徴とする画像処理装置の制御方法。
10. 少なくとも、アプリケーション制御部と、システム制御部を有する画像処理装置の制御方法であって、
    前記アプリケーション制御部は、
    アプリケーションの起動要求に応じて、該アプリケーションのクラスのクラスファイルを読み込み、当該クラスをロードさせる制御工程を有し、
    前記システム制御部は、
    前記クラスをロードして、生成するオブジェクトに使用するファイルサイズを確保し、スレッドに記録されたアプリケーション情報を前記確保したファイルサイズをディスク使用量として記録するとともに、当該オブジェクトを生成するオブジェクト生成工程を有し、
    前記アプリケーション制御部は、さらに、
    起動要求を受けたアプリケーションと前記アプリケーションを起動することによって使用したディスクとを、アプリケーション毎に紐付けて管理するディスク管理工程を有し、
    前記システム制御部は、複数のアプリケーションを一つのアプリケーションとして扱い、
    前記オブジェクト生成工程により生成されたオブジェクトが複数ある場合は、オブジェクト毎に、メモリを使用しているアプリケーションを関連付けることを特徴とする画像処理装置の制御方法。
11. 請求項９又は１０に記載の画像処理装置の制御方法における各ステップを前記画像処理装置に実行させるためのプログラム。

Images