JP5020121B2 - 情報処理装置、画像形成装置および情報処理方法 - Google Patents

Description

本発明は、情報処理装置、画像形成装置および情報処理方法に関するものである。

従来から、画像形成装置でプログラムが実行される際に使用されるリソースを適切に管理することが要求されている。リソースを適切に管理しないと、印刷処理などの途中でメモリ領域、ネットワークソケットなどのリソースが足りなくなり、処理がエラー終了することがある。

また、最近では、画像形成装置の基本的な機能の他に、機能を拡張するための様々なアプリケーションを追加することが提案されており、リソース使用量が増大する傾向にあるため、リソース管理の重要性はさらに高まってきている。

そのようなリソース管理を行う画像形成装置が提案されている（例えば、特許文献１，２参照）。

さらに、オペレーティングシステム（以下、ＯＳという）上で動作する仮想マシンが設けられ、仮想マシン上でアプリケーションを実行可能な画像形成装置が提案されている（例えば特許文献１参照）。特許文献１では、仮想マシンで使用されるリソース量を管理するリソース管理部がＯＳ上に設けられている。つまり、このリソース管理部により仮想マシン上で使用されるリソース量が一定量以下に制限される。

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

上記の装置では、ＯＳ上でリソース管理部が動作するため、仮想マシンでの使用リソース量を管理するためには、仮想マシンから使用リソース量への通知が必要になる。このため、仮想マシンをカスタム化する必要があり、汎用の仮想マシンをそのまま使用することは困難である。

本発明は、上記の問題に鑑みてなされたものであり、仮想マシンをカスタム化せずに、仮想マシン上で使用されるリソースの量を管理することができる情報処理装置、画像形成装置および情報処理方法を得ることを目的とする。

上記の課題を解決するために、本発明では以下のようにした。

本発明に係る情報処理装置は、演算処理装置で動作する仮想マシンと、仮想マシン上で動作し、仮想マシン上で動作するアプリケーションが使用するリソースの使用量を管理するリソース管理部と、仮想マシン上で実行されるリソース操作関数を含むリソース操作ライブラリと、仮想マシン上で動作し、アプリケーションにおいて使用されているクラスのオブジェクトをメモリに展開するとともに、クラスデータを解析し、オブジェクト内に記述されているリソース操作ライブラリにおけるリソース操作関数を、カスタム関数に置き換えるクラスローダとを備える。そして、カスタム関数が実行されると、カスタム関数の実行によるリソース使用量の変化量がリソース管理部に通知される。

これにより、リソース管理部が仮想マシン上で動作するため、仮想マシン自体は、汎用の仮想マシンを使用することができる。このため、仮想マシンをカスタム化せずに、仮想マシン上で使用されるリソースの量を管理することができる。ひいては、リソース管理のために必要となる開発規模を小さくすることができる。また、実行されるとリソース量が増加または減少するライブラリ関数が、リソース使用量の変化量を通知する関数へ置き換えられるため、リソース管理部は、アプリケーションが使用するライブラリ関数で使用／解放されるリソース量を考慮して、リソース量を管理することができる。

また、本発明に係る情報処理装置は、上記の情報処理装置に加え、次のようにしてもよい。この場合、クラスローダは、メモリに展開するオブジェクトのメモリ使用量をリソース管理部に通知する。

これにより、リソース管理部は、クラスローディングによるメモリ使用量に基づき、リソースとしてのメモリ領域を管理することができる。

また、本発明に係る情報処理装置は、上記の情報処理装置のいずれかに加え、次のようにしてもよい。この場合、クラスローダは、使用可能なメモリ領域がオブジェクトの展開に必要なメモリ領域より少ない場合には、オブジェクトの展開を禁止する。

これにより、クラスローディングによりメモリ領域が使用される際に、仮想マシン上で使用しているメモリ使用量が、メモリ領域の容量上限値を超えることを防止することができる。

また、本発明に係る情報処理装置は、上記の情報処理装置のいずれかに加え、次のようにしてもよい。この場合、オブジェクトが解放される場合、オブジェクトの解放によるリソース使用量の減少量がリソース管理部に通知される。

これにより、リソース管理部は、オブジェクト解放を考慮して、リソースとしてのメモリ領域を管理することができる。

また、本発明に係る情報処理装置は、上記の情報処理装置のいずれかに加え、次のようにしてもよい。この場合、カスタム関数が実行されると、カスタム関数の実行によるリソース使用量の変化量がリソース管理部に通知されるとともに、そのカスタム関数に置き換えられたリソース操作関数が呼び出され実行される。

これにより、カスタム関数自体には、リソース使用量の変化量を通知する処理のみを実行すればよいため、カスタム関数の開発が簡単になる。

また、本発明に係る情報処理装置は、上記の情報処理装置のいずれかに加え、次のようにしてもよい。この場合、カスタム関数が実行されると、使用可能なリソース量が、カスタム関数が使用するリソース量より少ない場合には、リソース操作関数の実行が禁止される。

これにより、ライブラリ関数が実行される際に、仮想マシン上で使用しているリソース量が、リソース量の上限値を超えることを防止することができる。

また、本発明に係る情報処理装置は、上記の情報処理装置のいずれかに加え、次のようにしてもよい。この場合、リソース管理部は、リソース使用量の変化量の通知に応じて、各時点での使用リソース量または使用可能なリソース量の情報を保持する。

また、本発明に係る情報処理装置は、上記の情報処理装置のいずれかに加え、次のようにしてもよい。この場合、リソースは、所定量のメモリ領域、所定数のネットワークソケットおよび所定数のスレッドのうちの少なくとも１つを含むものとされる。

また、本発明に係る情報処理装置は、上記の情報処理装置のいずれかに加え、次のようにしてもよい。この場合、仮想マシンは、Ｊａｖａ仮想マシンとされる。

これにより、仮想マシンとして、汎用のＪａｖａ仮想マシンを使用することができるため、リソース管理のために必要となる開発規模を小さくすることができる。

また、本発明に係る情報処理装置は、上記の情報処理装置のいずれかに加え、次のようにしてもよい。この場合、仮想マシンは、演算処理装置で動作するオペレーティングシステム上で動作する。

本発明に係る画像形成装置は、画像形成処理を行う画像形成処理部と、演算処理装置で動作する仮想マシンと、仮想マシン上で動作し画像形成処理部を使用するアプリケーションと、仮想マシン上で動作し、アプリケーションが使用するリソースの使用量を管理するリソース管理部と、仮想マシン上で実行されるリソース操作関数を含むリソース操作ライブラリと、仮想マシン上で動作し、アプリケーションにおいて使用されているクラスのオブジェクトをメモリに展開するとともに、クラスデータを解析し、オブジェクト内に記述されているリソース操作ライブラリにおけるリソース操作関数を、カスタム関数に置き換えるクラスローダとを備える。そして、カスタム関数が実行されると、カスタム関数の実行によるリソース使用量の変化量がリソース管理部に通知される。

これにより、リソース管理部が仮想マシン上で動作するため、仮想マシン自体は、汎用の仮想マシンを使用することができる。このため、仮想マシンをカスタム化せずに、仮想マシン上で使用されるリソースの量を管理することができる。

本発明に係る情報処理方法は、演算処理装置で仮想マシンを動作させ、仮想マシン上で動作するアプリケーションが使用するリソースの使用量を管理するリソース管理部を仮想マシン上で動作させ、仮想マシン上で動作するクラスローダで、アプリケーションにおいて使用されているクラスのオブジェクトをメモリに展開するとともに、クラスデータを解析し、オブジェクト内に記述されている、仮想マシン上で実行されるリソース操作ライブラリにおけるリソース操作関数を、カスタム関数に置き換え、カスタム関数が実行されると、カスタム関数の実行によるリソース使用量の変化量をリソース管理部に通知するものである。

これにより、リソース管理部が仮想マシン上で動作するため、仮想マシン自体は、汎用の仮想マシンを使用することができる。このため、仮想マシンをカスタム化せずに、仮想マシン上で使用されるリソースの量を管理することができる。

本発明によれば、仮想マシンをカスタム化せずに、仮想マシン上で使用されるリソースの量を管理することができる。

以下、図に基づいて本発明の実施の形態を説明する。

図１は、本発明の実施の形態に係る画像形成装置の構成を示すブロック図である。図１に示す画像形成装置は、情報処理装置の一例である。

図１において、ＣＰＵ１１は、プログラムを実行し、プログラムに記述された処理を実行する演算処理装置である。また、ＲＯＭ１２は、プログラムおよびデータを予め記憶した不揮発性のメモリである。また、ＲＡＭ１３は、プログラムを実行する際にそのプログラムおよびデータを一時的に記憶するメモリである。

ＨＤＤ１４は、各種プログラム、データなどを格納する記録媒体としてのハードディスク駆動装置である。ＨＤＤ１４には、ＯＳプログラム３１、ＶＭプログラム３２、基本リソース操作ライブラリ３３、カスタムリソース操作ライブラリ３４、アプリケーション管理プログラム３５、リソース管理プログラム３６、基本機能プログラム３７、およびアプリケーションプログラム３８が格納されている。

ＯＳプログラム３１は、オペレーティングシステムのプログラムである。オペレーティングシステムとしては、Ｌｉｎｕｘ（登録商標）、ＶｘＷｏｒｋｓなどが使用される。

ＶＭプログラム３２は、仮想マシンのプログラムである。仮想マシンとしては、この実施の形態では、Ｊａｖａ（登録商標）仮想マシンが使用される。Ｊａｖａ（登録商標）仮想マシン環境では、バイトコードと呼ばれる中間コードで記述されたプログラムが仮想マシンにより解釈され実行される。

基本リソース操作ライブラリ３３は、リソースを使用したり解放したりする処理を記述されたライブラリ関数（以下、リソース操作関数という）を有するプログラムである。リソースとしては、所定量のメモリ領域、所定数のネットワークソケット、所定数のスレッドなどが考えられる。

カスタムリソース操作ライブラリ３４は、基本リソース操作ライブラリ３３の各リソース操作関数に対応するライブラリ関数（以下、カスタム関数という）を有するプログラムである。カスタム関数には、対応するリソース操作関数を呼び出す処理、およびカスタム関数（呼び出すリソース操作関数を含む）により使用または解放されるリソース量（つまり、空きリソースの変化量）を通知する処理が記述される。

アプリケーション管理プログラム３５は、アプリケーションプログラム３８をロードしてアプリケーションを起動する処理が記述されたプログラムである。アプリケーション管理プログラム３５には、クラスローダプログラムが含まれる。

リソース管理プログラム３６は、仮想マシン上で使用されるリソース量を管理する処理が記述されたプログラムである。

基本機能プログラム３７は、印刷、コピー、ファクシミリ送信、ファクシミリ受信などの画像形成処理が記述されたプログラムである。

アプリケーションプログラム３８は、基本機能プログラムによる画像形成処理を使用するアプリケーションのプログラムである。

なお、ライブラリ３３，３４およびプログラム３５〜３８は、仮想マシン上で動作するプログラムである。

図２は、図１に示すライブラリ３３，３４およびプログラム３５〜３８により実現される処理部を階層的に示す図である。

図２において、ＯＳ５１は、ＣＰＵ１１によりＯＳプログラム３１が実行されることで実現される処理部である。

また、ＶＭ５２は、ＣＰＵ１１によりＶＭプログラム３２が実行されることで実現される処理部である。ＶＭ５２は、ＯＳ５１上で動作する仮想マシンである。

また、基本リソース操作処理部５３は、ＣＰＵ１１により基本リソース操作ライブラリ３３の１または複数のライブラリ関数（つまり、リソース操作関数）が実行されることで実現される処理部である。

また、カスタムリソース操作処理部５４は、ＣＰＵ１１によりカスタムリソース操作ライブラリ３４の１または複数のライブラリ関数（つまり、カスタム操作関数）が実行されることで実現される処理部である。カスタム関数が実行されると、カスタム関数の実行によるリソース量の変化量がリソース管理部５６に通知される。カスタム関数が実行されると、使用可能なリソース量が、カスタム関数が使用するリソース量より少ない場合には、リソース操作関数の実行が禁止される。つまり、カスタムリソース操作処理部５４は、使用可能なリソース量が、カスタム関数が使用するリソース量より少ない場合には、リソース操作関数の実行を禁止し、カスタム関数の実行によるリソース量の変化量をリソース管理部５６に通知する。なお、リソース操作関数の実行が禁止される場合には、使用リソース量は増減しないため、リソース管理部５６への通知は行われない。

また、アプリケーション管理部５５は、ＣＰＵ１１によりアプリケーション管理プログラム３５が実行されることで実現される処理部である。アプリケーション管理部５５は、カスタムクラスローダ６１を有する。

カスタムクラスローダ６１は、アプリケーション５８において使用されているクラスのオブジェクトをＲＡＭ１３に展開する処理部である。さらに、カスタムクラスローダ６１は、そのオブジェクトのメモリ使用量をリソース管理部５６に通知する。また、カスタムクラスローダ６１は、使用可能なメモリ領域がオブジェクトの展開に必要なメモリ領域より少ない場合には、オブジェクトの展開を禁止する。なお、オブジェクトの展開が禁止された場合、メモリ使用量は増加しないため、リソース管理部５６への通知は行われない。

また、カスタムクラスローダ６１は、アプリケーション５８において使用されているクラスのクラスデータを取得して解析し、オブジェクト内に記述されているリソース操作ライブラリにおけるリソース操作関数を、カスタム関数に置き換える。

また、リソース管理部５６は、ＣＰＵ１１によりリソース管理プログラム３６が実行されることで実現される処理部である。リソース管理部５６は、ＶＭ５２上で動作するアプリケーション５８が使用するリソースの使用量を管理する処理部である。リソース管理部５６は、使用しているリソース量の変化量の通知に応じて、各時点での使用リソース量または使用可能なリソース量の情報を保持するリソース監視部と、リソースの残存量を測定し、リソース残存量の問い合わせに応答するリソース測定部とを有する。

また、基本機能処理部５７は、ＣＰＵ１１により基本機能プログラム３７が実行されることで実現される処理部である。基本機能処理部５７は、ＶＭ５２に依存せず、ＯＳ５１上で動作し、画像形成処理に必要なデータ処理を実行するとともに、通信装置１６、印刷装置１７および読取装置１８を制御する。

また、アプリケーション５８は、ＣＰＵ１１によりアプリケーションプログラム３８が実行されることで実現される処理部である。アプリケーション５８は、基本機能処理部５７の機能を使用した複雑なアプリケーション処理を実行する。

処理部５３，５４，５７、管理部５５，５６およびアプリケーション５８は、それぞれ、ＶＭ５２上で動作する。ＶＭ５２がＪａｖａ（登録商標）仮想マシンである場合、処理部５３，５４，５７、管理部５５，５６およびアプリケーション５８のプログラムは、それぞれ、バイトコードで記述され、Ｊａｖａ仮想マシンで解釈された上でＣＰＵ１１により実行される。

また、図１において、操作パネル１５は、入力装置と表示装置を有する。入力装置は、ユーザによる操作を検出し、操作に応じた電気信号を出力する装置である。入力装置としては、例えばタッチパネル、キーなどが使用される。表示装置は、画像データに対応する画像信号を生成し表示する装置である。表示装置としては、液晶ディスプレイなどが使用される。

また、通信装置１６は、コンピュータネットワークおよび／または電話回線に接続され、基本機能処理部５７により制御され、外部から印刷、ファクシミリ送信などのジョブを受信したり、外部へのファクシミリ送信を実行したりする装置である。通信装置１６としては、ネットワークインタフェースカード、モデムなどが使用される。

また、印刷装置１７は、基本機能処理部５７により制御され印刷データに基づき所定の媒体への印刷を行う装置である。

また、読取装置１８は、基本機能処理部５７により制御され所定の媒体から光学的に画像を読み取り画像データとして出力する装置である。

これらの装置１６，１７，１８により、印刷、コピー、ファクシミリ送信、ファクシミリ受信などの画像形成処理が実現される。

次に、上記装置の動作について説明する。

ＶＭ５２がＪａｖａ（登録商標）仮想マシンとされる場合、ＶＭ５２で実行されるプログラムは、クラス単位で定義されている。そして、プログラムの実行時には、クラスのインスタンスであるオブジェクトがＲＡＭ１３に展開される。オブジェクトはバイトコードで記述される。そして、オブジェクトの内容が順番にＶＭ５２により解釈されて、プログラムに記述されている処理が順番に実行される。このとき、処理によっては、リソースを確保したり、解放したりすることがある。

以下、（ａ）クラスローディング、（ｂ）オブジェクトの実行、（ｃ）オブジェクトの解放の順番で、本実施の形態におけるリソース管理について説明する。

まず、クラスローディングにおけるリソース管理処理について説明する。図３は、図２におけるカスタムクラスローダ６１の動作を説明するフローチャートである。

クラスローダ６１は、対象のクラスデータを、アプリケーションプログラム３８、ライブラリ３３などから取得する（ステップＳ１）。アプリケーションプログラム３８、ライブラリ３３などは、ファイルとしてＨＤＤ１４に格納されていてもよいし、外部サーバに格納されていてもよい。外部サーバからクラスデータを取得する場合には、クラスローダ６１は、通信装置１６により外部サーバにアクセスし、クラスデータをダウンロードする。

クラスローダ６１は、クラスデータを取得すると、クラスデータの先頭から順番に１ラインずつコードを読み込み（ステップＳ２）、そのコード内に基本リソース操作ライブラリ３３のリソース操作関数の呼出が存在するか否かを判定する（ステップＳ３）。

そのコードにリソース操作関数の呼出が存在する場合、クラスローダ６１は、そのリソース操作関数の呼出を、そのリソース操作関数に対応するカスタム関数の呼出に置き換えた後（ステップＳ４）、そのコードを解釈する（ステップＳ５）。

一方、そのコードにリソース操作関数の呼出が存在しない場合、クラスローダ６１は、そのコードをそのまま解釈する（ステップＳ５）。

そして、クラスローダ６１は、クラスデータにおけるコードをすべて解釈したか否かを判定する（ステップＳ６）。解釈していないコードがある場合には、クラスローダ６１は、次のコードを読み込み（ステップＳ２）、そのコードについてステップＳ３からステップＳ５までの処理を同様に実行する。

このようにして、クラスデータにおけるすべてのコードの解釈が完了すると、クラスローダ６１は、すべてのコードの解釈結果に基づきＲＡＭ１３に展開されるオブジェクトのサイズを計算し（ステップＳ７）、リソース管理部５６に通知する（ステップＳ８）。

そして、クラスローダ６１は、すべてのコードの解釈結果に基づきそのクラスに対応するオブジェクトをＲＡＭ１３に展開する（ステップＳ９）。

なお、ステップＳ８でリソース管理部５６にメモリ使用量の増加を通知する前に、クラスローダ６１は、ＲＡＭ１３に確保されているリソースとしてのメモリ領域において、増加分以上の空き領域があるか否かをリソース管理部５６に問い合わせ、十分な空き領域がある場合のみ、ステップＳ８およびステップＳ９の処理を実行するようにしてもよい。十分な空き領域がない場合には、エラー処理が実行され、ステップＳ８およびステップＳ９の処理は実行されない。

このようにして、クラスローディング時には、オブジェクト展開による所定のメモリ領域における使用量が考慮されて、リソース管理が行われる。

次に、オブジェクト実行時のリソース管理処理について説明する。図４は、実施の形態におけるカスタム関数実行時の処理について説明するフローチャートである。

オブジェクト実行時に、クラスローダ６１により置き換えられたカスタム関数が呼び出されると、まず、そのカスタム関数で使用されるリソースが、そのカスタム関数で使用される量だけ確保可能か否かが判定される（ステップＳ２１）。このとき、リソース管理部５６に、そのリソースについての残存量が問い合わせられ、それに対する応答、およびカスタム関数で記述されている使用リソース量に基づき、判定が行われる。

そのカスタム関数で使用されるリソースが、そのカスタム関数で使用される量だけ確保可能であると判定された場合、カスタム関数の実行で増加するリソース使用量がリソース管理部５６に通知され（ステップＳ２２）、そのカスタム関数に対応するリソース操作関数が呼び出される（ステップＳ２３）。

一方、そのカスタム関数で使用されるリソースが、そのカスタム関数で使用される量だけ確保可能ではないと判定された場合、リソース操作関数は呼び出されず、エラー処理が実行される（ステップＳ２４）。

なお、リソースを解放するリソース操作関数がカスタム関数で呼び出される場合には、カスタム関数の実行で減少するリソース使用量がリソース管理部５６に通知され、そのカスタム関数に対応するリソース操作関数が呼び出される。

このようにして、オブジェクト実行時には、リソース操作を行う関数の呼び出しによるリソース使用量の増減が考慮されて、リソース管理が行われる。

次に、オブジェクト解放時のリソース管理処理について説明する。図５は、実施の形態におけるオブジェクト解放時の処理について説明するフローチャートである。

クラスローディングにより展開されたオブジェクトは、オブジェクトを解放するリソース操作関数の呼出、またはガベージコレクタによるガベージコレクションにより解放される。オブジェクトが解放されると、そのオブジェクトにおいて使用されていたリソースも解放される。なお、オブジェクトを解放するリソース操作関数の呼出は、クラスローダ６１により、対応するカスタム関数の呼び出しに置き換えられる。

そして、オブジェクトを解放するカスタム関数の呼び出し、またはガベージコレクションが発生すると、解放されるリソース量、つまりリソース使用量の減少分がリソース管理部５６に通知され（ステップＳ４１）、リソース操作関数を呼び出すことでリソースが解放される（ステップＳ４２）。

このようにして、オブジェクト解放時には、解放されるリソース量に基づく、リソース使用量の減少が考慮されて、リソース管理が行われる。

以上のように、上記実施の形態によれば、リソース管理部５６は、ＶＭ５２上で動作し、ＶＭ５２上で動作するアプリケーション５８が使用するリソースの使用量を管理する。これにより、リソース管理部５６が仮想マシン上で動作するため、仮想マシン自体は、汎用の仮想マシンを使用することができる。このため、仮想マシンをカスタム化せずに、仮想マシン上で使用されるリソースの量を管理することができる。ひいては、リソース管理のために必要となる開発規模を小さくすることができる。また、リソース管理部５６は、ＶＭ５２上で動作するため、ＯＳ５１に依存せずに済む。つまり、同一種類のＶＭ５２が実装されていれば、ＯＳ５１の種類に関係なく、同一のリソース管理部５６を使用することができる。

また、上記実施の形態によれば、クラスローダ６１は、ＶＭ５２上で動作し、ＲＡＭ１３に展開するオブジェクトのメモリ使用量をリソース管理部５６に通知する。これにより、リソース管理部５６は、クラスローディングによるメモリ使用量に基づき、リソースとしてのメモリ領域を管理することができる。また、クラスローダ６１は、使用可能なメモリ領域がオブジェクトの展開に必要なメモリ領域より少ない場合には、オブジェクトの展開を禁止するようにしてもよい。これにより、クラスローディングによりメモリ領域が使用される際に、仮想マシン上で使用しているメモリ使用量が、メモリ領域の容量上限値を超えることを防止することができる。

また、上記実施の形態によれば、オブジェクトが解放される場合、オブジェクトの解放によるリソース使用量の減少量がリソース管理部５６に通知される。これにより、リソース管理部５６は、オブジェクト解放を考慮して、リソースとしてのメモリ領域を管理することができる。

また、上記実施の形態によれば、クラスローダ６１は、クラスデータを解析し、オブジェクト内に記述されている基本リソース操作ライブラリ３３におけるリソース操作関数を、カスタム関数に置き換える。そして、カスタム関数がＶＭ５２上で実行されると、カスタム関数の実行によるリソース使用量の変化量がリソース管理部５６に通知される。これにより、実行されるとリソース量が増加または減少するライブラリ関数が、リソース量の変化量を通知する関数へ置き換えられるため、リソース管理部５６は、アプリケーションが使用するライブラリ関数で使用／解放されるリソース量を考慮して、リソース量を管理することができる。

上述のように、リソース管理に関連する処理部（リソース管理部５６、カスタムリソース操作処理部５４およびクラスローダ６１）は、すべてＶＭ５２上で動作するため、ＯＳ５１に依存せずに済む。つまり、同一種類のＶＭ５２が実装されていれば、ＯＳ５１の種類に関係なく、これらを使用することができる。

なお、上述の実施の形態は、本発明の好適な例であるが、本発明は、これらに限定されるものではなく、本発明の要旨を逸脱しない範囲において、種々の変形、変更が可能である。

例えば、上記実施の形態では、情報処理装置の一例として画像形成装置を挙げているが、画像形成装置以外の組み込み装置にも適用可能である。

また、上記実施の形態において、ＶＭ５２として、Ｊａｖａ仮想マシンの代わりに、他の仮想実行環境を使用してもよい。

また、上記実施の形態において、図１および図２では、アプリケーションプログラム３８およびアプリケーション５８は、１つのみを示しているが、それらは複数でもよい。

また、上記の実施の形態では、クラスローダ６１によりクラスローディング時にリソース操作関数がカスタム関数に置き換えられているが、事前にアプリケーションプログラム３８においてリソース操作関数の代わりにカスタム関数が記述されるようにしてもよい。

また、上記の実施の形態において、リソース使用量の上限値は、機能ごと、アプリケーション５８ごとなど、複数の条件のそれぞれに対して異なるように設定してもよい。また、予め設定されるリソース使用量の上限値に対する所定の割合に到達したらリソースを新たに確保できないようにしてもよい。

本発明は、例えば、仮想マシンを備えている組み込み装置に適用可能である。

本発明の実施の形態に係る画像形成装置の構成を示すブロック図である。 図１に示すライブラリおよびプログラムにより実現される処理部を階層的に示す図である。 図２におけるカスタムクラスローダの動作を説明するフローチャートである。 実施の形態におけるカスタム関数実行時の処理について説明するフローチャートである。 実施の形態におけるオブジェクト解放時の処理について説明するフローチャートである。

符号の説明

１１ ＣＰＵ（演算処理装置）
１３ ＲＡＭ（メモリ）
３３ 基本リソース操作ライブラリ（リソース操作ライブラリ）
５１ オペレーティングシステム
５２ ＶＭ（仮想マシン）
５６ リソース管理部
５７ 基本機能処理部（画像形成処理部）
５８ アプリケーション
６１ カスタムクラスローダ（クラスローダ）

Claims (12)

1. 演算処理装置で動作する仮想マシンと、
   前記仮想マシン上で動作し、前記仮想マシン上で動作するアプリケーションが使用するリソースの使用量を管理するリソース管理部と、
   前記仮想マシン上で実行されるリソース操作関数を含むリソース操作ライブラリと、
   前記仮想マシン上で動作し、前記アプリケーションにおいて使用されているクラスのオブジェクトをメモリに展開するとともに、クラスデータを解析し、前記オブジェクト内に記述されている前記リソース操作ライブラリにおけるリソース操作関数を、カスタム関数に置き換えるクラスローダとを備え、
   前記カスタム関数が実行されると、前記カスタム関数の実行によるリソース使用量の変化量が前記リソース管理部に通知されること、
   を特徴とする情報処理装置。
2. 前記クラスローダは、前記メモリに展開するオブジェクトのメモリ使用量を前記リソース管理部に通知すること、
   を特徴とする請求項１記載の情報処理装置。
3. 前記クラスローダは、使用可能なメモリ領域が前記オブジェクトの展開に必要なメモリ領域より少ない場合には、前記オブジェクトの展開を禁止することを特徴とする請求項２記載の情報処理装置。
4. 前記オブジェクトが解放される場合、前記オブジェクトの解放によるリソース使用量の減少量が前記リソース管理部に通知されることを特徴とする請求項２記載の情報処理装置。
5. 前記カスタム関数が実行されると、前記カスタム関数の実行によるリソース使用量の変化量が前記リソース管理部に通知されるとともに、そのカスタム関数に置き換えられた前記リソース操作関数が呼び出され実行されることを特徴とする請求項１記載の情報処理装置。
6. 前記カスタム関数が実行されると、使用可能なリソース量が、前記カスタム関数が使用するリソース量より少ない場合には、前記リソース操作関数の実行が禁止されることを特徴とする請求項１記載の情報処理装置。
7. 前記リソース管理部は、リソース使用量の変化量の通知に応じて、各時点での使用リソース量または使用可能なリソース量の情報を保持することを特徴とする請求項１記載の情報処理装置。
8. 前記リソースは、所定量のメモリ領域、所定数のネットワークソケットおよび所定数のスレッドのうちの少なくとも１つを含むことを特徴とする請求項１記載の情報処理装置。
9. 前記仮想マシンは、Ｊａｖａ仮想マシンであることを特徴とする請求項１記載の情報処理装置。
10. 前記仮想マシンは、前記演算処理装置で動作するオペレーティングシステム上で動作することを特徴とする請求項１記載の情報処理装置。
11. 画像形成処理を行う画像形成処理部と、
    演算処理装置で動作する仮想マシンと、
    前記仮想マシン上で動作し前記画像形成処理部を使用するアプリケーションと、
    前記仮想マシン上で動作し、前記アプリケーションが使用するリソースの使用量を管理するリソース管理部と、
    前記仮想マシン上で実行されるリソース操作関数を含むリソース操作ライブラリと、
    前記仮想マシン上で動作し、前記アプリケーションにおいて使用されているクラスのオブジェクトをメモリに展開するとともに、クラスデータを解析し、前記オブジェクト内に記述されている前記リソース操作ライブラリにおけるリソース操作関数を、カスタム関数に置き換えるクラスローダとを備え、
    前記カスタム関数が実行されると、前記カスタム関数の実行によるリソース使用量の変化量が前記リソース管理部に通知されること、
    を特徴とする画像形成装置。
12. 演算処理装置で仮想マシンを動作させ、
    前記仮想マシン上で動作するアプリケーションが使用するリソースの使用量を管理するリソース管理部を前記仮想マシン上で動作させ、
    前記仮想マシン上で動作するクラスローダで、前記アプリケーションにおいて使用されているクラスのオブジェクトをメモリに展開するとともに、クラスデータを解析し、前記オブジェクト内に記述されている、前記仮想マシン上で実行されるリソース操作ライブラリにおけるリソース操作関数を、カスタム関数に置き換え、
    前記カスタム関数が実行されると、前記カスタム関数の実行によるリソース使用量の変化量を前記リソース管理部に通知する、
    ことを特徴とする情報処理方法。

Images