JP2017157175A - 情報処理装置及びライブラリ管理方法 - Google Patents

Abstract

【課題】画像形成装置等ではファイルディスクリプタの数には上限があり、消費数が増加していけば、アプリケーションが動作のために使用可能なファイルディスクリプタ（ＦＤ）数が少なくなる。
【解決手段】開いたライブラリの数に応じた量のＦＤを消費するクラスローダー３０２を用いた情報処理装置において、アプリケーションを起動する前に、ライブラリ管理モジュール３０４は、そのアプリケーションと既に起動済みのアプリケーションとについて設定されたＦＤの上限値の合計から、情報処理装置で利用できるＦＤの総数を差し引いた超過数が０より大きければ、その超過数が、起動するアプリケーションと起動済みのアプリケーションとにより使用されるライブラリの数の合計よりも少ないか判定し、少なければ、アプリケーションにより使用されるライブラリに含まれたクラスを統合ライブラリ３０５に統合する。
【選択図】図３

Description

本発明は、クラスパスに設定されているライブラリを管理する情報処理装置及びライブラリ管理方法に関わる。

Ｊａｖａ（登録商標）の実行環境において、クラス（実行に必要なコード）のロードはクラスローダーによって行われる。クラスは、ＪＡＲ（Ｊａｖａ Ａｒｃｈｉｖｅ）形式のライブラリの中にあるクラスファイルで定義されている。ライブラリは複数のクラスのクラスファイルから構成されており、特定の機能毎に分けられていることが多い。なお、ライブラリが存在する場所を示すパスはクラスパスとして、あらかじめＪａｖａ（登録商標）の実行環境に設定しておく必要がある。これはクラスのロード時に、クラスローダーが、クラスパスに設定されているライブラリから、ロードするクラスを探索するためである。ここで、クラスローダーは、ライブラリを参照してクラスを探索するため、ファイルディスクリプタを消費することになる。Ｊａｖａ（登録商標）の実行環境では、パフォーマンスを向上させるため、あるいはライブラリへの参照が切れて動作が不安定になることを防ぐために、一度参照したライブラリは、実行環境上で動作するプログラムが終了するまで参照される。そのため、クラスローダーがライブラリを参照するために消費したファイルディスクリプタはプログラムが終了するまで消費され続けることになる。

組込機器において、アプリケーションの実行環境である情報処理装置には、使用可能なリソースに制限がある。ファイルディスクリプタもリソースの一種であり、使用可能なファイルディスクリプタ数に制限がある。そのため、以下のようなことが行われている。まず、アプリケーションの作成者はアプリケーションが使用するリソース量について上限値を定める。そして、管理者ユーザーがアプリケーションを開始する際に、その上限値に基づいて、アプリケーション管理フレームワークは情報処理装置の使用可能なリソース量を超えないことを確認する。従来技術として、全く使用されることのないクラスを検知して、クラスパスから使用されることのないクラスがあるライブラリを削除する技術がある（例えば特許文献１。

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

特許文献１は、クラスパスから使用されるクラスがあるライブラリに対しては、そのまま残している。つまり、クラスパスから使用されるクラスがあるライブラリの数が多いと、ファイルディスクリプタを多く消費する。そのため、ファイルディスクリプタの使用可能な数を超えてしまうと、結果として、起動処理に影響を及ぼす。特に、ソフトウェアのアップデートや機能拡張により、ライブラリの増加が重なっていくと、ファイルディスクリプタの消費数が増えることになる。

そこで本願発明の目的は、使用するライブラリが増加したとしても、ファイルディスクリプタの消費を抑制することにある。

上記課題を解決するために、本発明は以下の構成を有する。

開いたライブラリの数に応じた量のリソースを消費する情報処理装置であって、
インストールされた起動対象プログラムを起動する前に、該起動対象プログラムと起動済みのプログラムとについて設定されたリソースの上限値の合計から、前記情報処理装置で利用できるリソースの総数を差し引いた超過数が０より大きいか判定する第１の判定手段と、
前記第１の判定手段により大きいと判定された場合には、前記超過数が、前記起動対象プログラムと前記起動済みのプログラムとにより使用されるライブラリの数の合計よりも少ないか判定する第２の判定手段と、
前記第２の判定手段により少ないと判定された場合には、前記起動対象プログラムと前記起動済みのプログラムとにより使用されるライブラリに含まれたクラスを統合ライブラリに統合する統合手段とを有する。

本発明によれば、起動の処理に影響を及ぼすことなくクラスロード時のファイルディスクリプタの消費を抑制することが可能となる。

本発明の実施例のシステムの全体構成の一例を示す図である。 画像形成装置のハードウェア構成の一例を示す図である。 本発明の実施例のアプリケーションの実行環境の構成の一例を示す図である。 本発明の実施例における起動オプション設定ファイルの一例を示す図である。 本発明の実施例におけるアプリケーションの構成の一例を示す図である。 画像形成装置におけるライブラリ配置の一例を示した模式図である。 ライブラリ内部の構成の一例を示した模式図である。 本発明の実施例における処理フローの一例を示した図である。 本発明の第二の実施例における処理フローの一例を示した図である。

以下、本発明を実施するための形態について図面を用いて説明する。

［実施例１］
図１は本発明の装置の全体構成を示す図である。画像形成装置１００は本実施例を実装した情報処理装置の一例であり、例えば多機能周辺装置（ＭＦＰ）である。情報処理装置１０１は画像形成装置１００を管理するための管理用情報処理装置である。ネットワーク１２０は画像形成装置１００と管理用情報処理装置１０１を接続する。管理用情報処理装置１０１は画像形成装置１００をネットワーク１２０経由で利用するために用いられる。アプリケーションＡ１１０は画像形成装置１００上で動作するアプリケーションの一つの例である。アプリケーションＢ１１１は同様に画像形成装置１００上で動作するアプリケーションのもう一つの例である。さらにアプリケーションＣ１１２は同様に画像形成装置１００上で動作するアプリケーションのさらなる一つの例である。画像形成装置１００上では一つ、あるいは複数のアプリケーションを動作させることが可能である。ここではアプリケーションを三つ例示している。以後、「アプリケーション１１ｎ」という表現は、アプリケーションＡ１１０、アプリケーションＢ１１１、アプリケーションＣ１１２にて代表されるような一つまたは複数のアプリケーションを指す。一般利用者および管理者は画像形成装置１００の基本機能、アプリケーション１１ｎ、および、画像形成装置１００やアプリケーション１１ｎを管理するためのリソース管理装置を利用することが可能である。利用に当たっては、画像形成装置１００を直接操作、もしくはネットワーク１２０経由で管理用情報処理装置１０１から操作することが可能である。

＜画像形成装置のハードウェア構成＞
図２は画像形成装置１００のハードウェア構成を図式化したものである。コア部２００はプロセッサやメモリなどを含む制御部であり、コア部２００に接続された種々のデバイスを、プロセッサとメモリとが共働してプログラムを実行することで制御する。また、アプリケーションの実行環境を実現し、インストールされたアプリケーションを実行する。コア部２００には、ユーザーインターフェース部２０１、記憶装置２０２、ネットワーク１２０に接続するためのネットワークインターフェース部２０３、スキャナー部２０４、プリンター部２０５、フィニッシャー部２０６などが周辺デバイスとして接続されている。コア部２００はこれらデバイスを制御し、その機能をユーザーインターフェース部２０１あるいはネットワーク１２０を介してユーザに提供するとともに、アプリケーションに対しても提供している。

＜アプリケーション実行環境＞
図３は本実施例における画像形成装置１００の上でアプリケーション１１ｎを実行するためのアプリケーション実行環境である。
アプリケーション実行基盤３０１は、Ｊａｖａ（登録商標）の実行環境である。アプリケーション実行基盤３０１は、起動モジュール３００から指示を以って起動する。クラスローダー３０２は、アプリケーション実行基盤３０１で、クラスを実行するために、当該クラスをロードするモジュールを示す。ライブラリ管理モジュール３０４は、クラスパスに設定されているライブラリを一つの統合ライブラリ３０５として生成処理を行う。

ユーザーが画像形成装置１００の電源を入れると、起動モジュール３００は、ライブラリ管理モジュール３０４に対して、統合ライブラリ３０５の作成処理を指示する。そして、統合ライブラリ３０５の生成処理が完了した後で、起動モジュール３００はアプリケーション実行基盤３０１の起動を開始する。

アプリケーション実行基盤３０１がクラスの実行処理を行う際に、クラスのロードはクラスローダー３０２によって行われる。クラスのロードを実行する際に、クラスローダー３０２はクラスパスに設定されているライブラリから、実行処理に必要なクラスを探索する。クラスはアプリケーション実行基盤３０１が処理を実行するための実行コードであり、ライブラリに定義されている。ライブラリが格納されている場所は、クラスパスに設定されており、クラスローダー３０２はクラスパスを元にロードするクラスを特定する。

クラスパスには、システムが必要とするシステム用クラスパスと、各アプリケーション１１ｎ用のクラスをロードする際に必要なアプリ用クラスパス（以降、アプリクラスパスと称する）が存在する。これらシステム用クラスパスとアプリクラスパスを合わせてクラスパスと呼ぶ。システム用クラスパスには、ブートクラスパスとシステムクラスパスの少なくとも一方が含まれる。ブートクラスパスはＪａｖａ（登録商標）の実行環境を起動するために必要なクラスを含むライブラリの所在場所を示すパスである。システムクラスパスはアプリケーション実行基盤３０１、及びアプリ管理フレームワーク３０３を起動するために必要なクラスを含むライブラリの所在場所を示すパスである。システム用クラスパスは、起動モジュール３００がアプリケーション実行基盤３０１を起動する際に、起動オプションの一部として通知する。そして、アプリケーション実行基盤３０１は通知されたシステムクラスパスを参照し、起動時に使用する。一方アプリクラスパスは、アプリケーション内に含まれるアプリケーション設定ファイル（以下、アプリ設定ファイルとも呼ぶ。）に存在する。アプリクラスパスはアプリケーション管理フレームワーク３０３が参照し、開始するアプリケーション専用のクラスパスとして設定する。そのため、アプリクラスパスといっても異なるアプリケーション１１ｎ同士に対するアプリクラスパスはまったく異なった種類のクラスパスとなる。

クラスを実行する際には、まず、クラスローダー３０２はシステム用クラスパスもしくはアプリクラスパスに設定されたライブラリの中からクラスを探索する。そして、ライブラリの中にクラスが存在する場合は、クラスローダー３０２が該ライブラリから目的のクラスをロードし、アプリケーション実行基盤３０１がロードしたクラスを実行することとなる。

画像形成装置１００のシステムが動き始めてから、ユーザーによって電源が切られるまで、ロードしていないクラスが実行されると、このようなクラスローダー３０２によるクラスのロード処理が行われる。また、クラスには同名のクラスが衝突しないように、アプリケーション作成者によって、あらかじめ名前空間が与えられている。ライブラリは、一つ以上のクラスをＪＡＲ（Ｊａｖａ Ａｒｃｈｉｖｅ）ファイルとして圧縮したファイルになっている。ライブラリの中でもクラスが衝突するのを防ぐために、ＪＡＲファイルには名前空間に対応したディレクトリ階層が構成され、その中にクラスのファイルが配置されていることが一般的である。本実施例においても、ライブラリ内が名前空間のディレクトリ階層で構成されている例を使って説明する。

アプリケーション管理フレームワーク３０３は、アプリケーション１１ｎのインストールとアンインストール、及び、実行・停止を管理する。アプリケーション実行環境内にインストールしたり、アプリケーション実行環境内のアプリケーションの実行を開始したり、停止する際には、アプリケーション管理フレームワーク３０３を利用する。アプリケーション管理フレームワーク３０３は、画像形成装置１００の管理者からのリクエストに応じて、アプリケーションのインストール処理やアプリケーション開始処理を行う。その際に、アプリケーション管理フレームワーク３０３はアプリケーション内のアプリ設定ファイルを参照して、該ファイルに宣言されているリソースの上限値を取得する。そして、アプリケーション実行環境内のリソースの空き容量に収まるか否かを判定し、空き容量に収まるようであれば、アプリケーション開始処理を実行する。

統合ライブラリ３０５は、ライブラリ管理モジュール３０４によって作成される。ライブラリ管理モジュール３０４は起動モジュール３００から統合ライブラリ作成処理の指示を受信することで動作する。ライブラリ管理モジュール３０４は、起動オプション設定ファイルのシステム用クラスパスやアプリケーション設定ファイルのアプリクラスパスに設定されているライブラリを解凍する。そして、解凍して展開したクラスを新しい統合ライブラリとしてＪＡＲファイル形式で圧縮し直す。その後、ライブラリ管理モジュールは、統合ライブラリを作成した後で、起動オプション設定ファイルのクラスパス、もしくは、アプリケーション設定ファイルのアプリクラスパスの設定を新しく生成した統合ライブラリになるように変更する。

システム用クラスパスもしくはアプリクラスパスとして設定されていた複数ライブラリ内のクラス群をまとめた統合ライブラリのみをクラスパスに設定することで、クラスローダー３０２は統合ライブラリ３０５のみを参照して必要なクラスを探索可能となる。統合ライブラリ３０５に含まれるクラスは、一度クラスローダー３０２によってロードされると、アプリケーション実行基盤３０１、アプリケーション管理フレームワーク３０３、アプリケーション１１ｎから実行可能となる。

＜起動オプション設定ファイルの一例＞
図４は本実施例における起動オプション設定ファイルの一例を示した図である。図４（ａ）は、本実施例におけるライブラリ管理モジュール３０４によって変更される前の起動オプション設定ファイル４００を示す図である。起動オプション設定ファイル４００は、ライブラリ管理モジュール３０４が統合ライブラリ３０５を作成してファイルの内容を変更する前の起動オプション設定ファイルである。パス４０１は、アプリケーション実行基盤３０１を起動するための実行ファイルがある所在場所を示すパスである。パス４０２は、ライブラリの所在場所を示すパスである。ライブラリ４０３は、第一のクラスパスとして設定されているライブラリである。第一のクラスパス４０２に設定されたライブラリ４０３には、アプリケーション実行基盤３０１やアプリ管理フレームワーク３０３が処理を実行するのに必要なクラス群を含んでいる。メインプログラム４０４は、アプリケーション実行基盤３０１がアプリ管理フレームワーク３０３を起動するために必要なプログラムである。

図４（ｂ）は本実施例におけるライブラリ管理モジュール３０４によって変更された後の起動オプション設定ファイル４１０を示す図である。起動オプション設定ファイル４１０は、ライブラリ管理モジュール３０４が統合ライブラリを作成してファイルの内容を変更した後の起動オプション設定ファイルである。起動モジュール３００は起動オプション設定ファイル４１０の内容を読み込み、読み込んだ内容をアプリケーション実行基盤３０１の起動オプションとして使用する。ライブラリ４１１は、第一のクラスパスとして設定されている統合ライブラリ３０５である。図４の例では、図４（ａ）に示された：／Ｄｅｖｉｃｅ／ｓｙｓｔｅｍ／ｌｉｂ／ｌｉｂｓｙｓｔｅｍ００１．ｊａｒ、：／Ｄｅｖｉｃｅ／ｓｙｓｔｅｍ／ｌｉｂ／ｌｉｂｓｙｓｔｅｍ００２．ｊａｒ、：／Ｄｅｖｉｃｅ／ｓｙｓｔｅｍ／ｌｉｂ／ｌｉｂｓｙｓｔｅｍ００３．ｊａｒ等のライブラリがひとつに統合されたライブラリである。ライブラリ管理モジュール３０４は統合ライブラリを作成した後、起動オプション設定ファイル４００のクラスパス設定に統合ライブラリを追加し、統合ライブラリ以外のライブラリを第一のクラスパス４０２から削除する。

＜アプリケーションファイルの例＞
図５（ａ）は本実施例におけるアプリケーション１１ｎを構成するファイルについて説明するための図である。アプリケーション１１ｎは幾つかの種類のファイルを抱えている。アプリケーション実行コードファイル５００は、アプリケーションの実行コードなどを含む。内包ライブラリ５０１は、アプリケーションの処理を実行するために必要なライブラリを示す。アプリケーション１１ｎの処理の実行時に、クラスパス４０２に設定されているライブラリ４０３では特定のクラスが不足し、機能を実現できない場合がある。そのような場合を回避するために、アプリケーション作成者はアプリケーション用のライブラリをアプリケーション内包ライブラリ５０１として用意する。アプリケーション設定ファイル５０２は、アプリケーションの基本情報を含む。アプリケーション設定ファイル５０２にはアプリケーションＩＤ等の基本情報や、アプリケーションが使用するファイルディスクリプタ等のリソースの上限値、アプリクラスパスがアプリケーション作成者によって定義されている。

図５（ｂ）は、アプリケーション設定ファイル（アプリ設定ファイル）５０２の一例を示す図である。アプリケーションＩＤ５１１は、アプリケーション管理フレームワークが３０３各アプリケーション１１ｎを一意に識別するための識別情報を示す。アプリケーション名５１２は、アプリケーション１１ｎの名称を示す。アプリケーション名５１２は画像形成装置１００のユーザーインターフェース部２０１の表示や、アプリケーション管理フレームワーク３０３がユーザーに対して表示する際に使用する。リソース上限値５１３は、アプリケーション１１ｎが使用するリソースの上限値を示す。アプリケーションの作成者は予めアプリケーション１１ｎが使用するリソースの上限値を算出しておき、アプリケーション設定ファイル５０２にリソース上限値５１３として定義する。リソース上限値５１３は、リソースの種類ごとにその上限値を示す。図５（ｂ）の例では、たとえばファイルディスクリプタについては８が設定されている。アプリケーション管理フレームワーク３０３はアプリケーション１１ｎをインストールして開始する際に、リソース上限値５１３を参照する。そして、現在のアプリケーション実行環境内のリソースの空き容量に収まるか否かを判定し、空き容量の収まるようであれば、アプリケーションを開始する。アプリケーション実行環境内で利用できるリソースの上限は予め定めておくことができる。アプリクラスパス５１４は、アプリケーション１１ｎの処理を実行する際に必要なアプリケーション実行ファイル５００と、アプリケーション内包ライブラリ５０１の場所を示す経路情報を示す。クラスパスには各ライブラリが存在する場所のパスが記載されていれることを示す。

図５（ｃ）は、ライブラリ管理モジュール３０４が、アプリクラスパス５１４に記載されていた内容、たとえば内包ライブラリ５０１の所在を、統合ライブラリの所在に変更した後のアプリケーション設定ファイルの一例を示した図である。ライブラリ管理モジュール３０４は統合ライブラリの作成指示を受信すると、アプリケーション設定ファイル５０２に記載されているアプリクラスパス５１４を参照する。そして、アプリクラスパスに設定されているすべてのアプリケーション内包ライブラリ５０１を解凍し、ＪＡＲファイル形式で再圧縮、統合ライブラリを生成する。統合ライブラリを生成した後で、ライブラリ管理モジュール３０４は、該アプリクラスパス５１４の記載を、生成した統合ライブラリに変更する。

アプリケーション設定ファイル５２０は、アプリクラスパス５１４の記載を、統合ライブラリのパスへと変更した後のアプリケーション設定ファイルを示す。アプリクラスパス５２１は、前述のように変更されたアプリクラスパスを示し、アプリケーション実行コードファイル５００と、統合ライブラリのパスを記載している。ここでは、アプリクラスパス５１４で記載していたライブラリ、ｌｉｂｐａ１．ｊａｒ、ｌｉｂｐａ２．ｊａｒ、ｌｉｂｐａ３．ｊａｒ、ｌｉｂｐａ４．ｊａｒ、ｌｉｂｐａ５．ｊａｒが、統合ライブラリｌｉｂｉｎｔｅｇ．ｊａｒに置き換わっていることを示している。ファイルディスクリプタ数５２２には、アプリケーションが使用するファイルディスクリプタ数が記載されている。図５（ｃ）では、アプリケーションが使用するファイルディスクリプタ数の最大値は統合前と変わらず８であるが、統合ライブラリへの置き換えによって、使用するファイルディスクリプタ数を書き換えてもよい。ライブラリの統合によって、使用するファイルディスクリプタの数は、統合されたライブラリを使用するアプリケーション全体でひとつになる。そのため、使用するファイルディスクリプタ数の最大値を、統合前の数からクラスパスの数を減じた値に書き換えてよい。図５（ｃ）の例では、５つのライブラリを統合しているので、最大値５２１を、８−５＝３に書き換えてもよい。統合ライブラリから初めてクラスをロードする際にはひとつのファイルディスクリプタが使用されるが、統合ライブラリのパスを図４（ｂ）のように起動オプション設定ファイルに記述しておくことで、アプリケーション設定ファイルでのファイルディスクリプタの宣言値を上述したように変更できる。

＜ライブラリ配置の一例＞
図６は、画像形成装置１００内にあるライブラリ配置の一例をツリー状で示した構成図である。フォルダ６０１は、クラスパス４０２に設定されているライブラリを配置するためのフォルダである。図６では、統合されたライブラリが画像形成装置１００（図６ではＤｅｖｉｃｅにより示されている）の内部に残っているが、ストレージの使用リソースを軽減させるために、クラスパス４０２の設定から統合前のライブラリ４０３を削除した後に、それらライブラリもライブラリ管理モジュール３０４が削除しても良い。統合ライブラリ６０２は、ライブラリ管理モジュール３０４が作成した統合ライブラリである。ライブラリ管理モジュール３０４は統合ライブラリ６０２を作成した後、この統合ライブラリ６０２をクラスパス４１１に設定する。フォルダ６０３は、画像形成装置１１ｎにインストールされたアプリケーション１１ｎを配置するためのフォルダである。アプリケーション管理フレームワーク３０３は、アプリケーション１１ｎをインストールする際に、アプリケーション内包ライブラリ５０１をアプリケーション１１ｎから取り出し、アプリ格納用フォルダ６０３に配置する。本実施例では、簡単にするため、図６でライブラリをまとめて配置した例としているが、起動オプションであるクラスパス４０２、４１１や、アプリクラスパス５１４と整合性が取れていれば、任意の場所に配置しても良い。

＜クラスファイルの配置例＞
図７は本実施例のライブラリ内にあるクラスファイルの配置の一例をツリー状で示した構成図である。
図７（ａ）は、ライブラリ管理モジュール３０４が、クラスファイルを集めて圧縮するために解凍するライブラリ内を示した図である。クラスファイル７０１〜７０４はクラスパス４０２に設定されているライブラリ内のクラスファイルである。クラスファイル７０５〜７０６はアプリクラスパス５１４に設定されているライブラリ内のクラスファイルである。
図７（ｂ）は、ライブラリ管理モジュール３０４がライブラリを解凍した後、全てのクラスファイルを圧縮して作成した統合ライブラリ内を示した図である。クラスファイル７１０は、クラスパス４１１に設定されている統合ライブラリ内のクラスファイルのである。図７（ａ）に記載されているクラスファイル７０１〜７０６は、統合ライブラリ内に全て配置されているため、クラスローダー３０１はこの統合ライブラリからクラスを探索するだけで、処理の実行に必要なクラスを見つけることが出来る。

＜アプリケーション起動時の処理（１）＞
本実施例におけるアプリケーション起動時の処理フローについて、図８のフローチャートを用いて説明する。本実施例は、アプリケーション管理フレームワーク３０３がアプリケーションのインストールを行い、アプリケーション管理フレームワーク３０３が管理者ユーザーからのリクエストの受信に応じて、もしくは自動的にアプリケーションの起動を行うところから開始する。図８の手順によりこれから起動されるアプリケーションを起動対象アプリケーションまたは起動対象プログラム、図８の開始時点で既に起動されているアプリケーションを起動済みアプリケーションまたは起動済みプログラムと呼ぶことにする。起動済みアプリケーションは、そのアプリケーションが使用するライブラリを開く際にファイルディスクリプタが既に消費されているが、起動対象アプリケーションが使用するライブラリはまだ開かれておらず、そのためのファイルディスクリプタはまだ消費されていない。

アプリケーションの起動処理が開始されると、アプリケーション管理フレームワーク３０３は、起動対象アプリケーションのアプリケーション設定ファイル５０２から、該アプリケーションの使用するファイルディスクリプタ（以降、ＦＤと略す）数を取得する（Ｓ８０１）。アプリケーションが使用するＦＤ数は、図５（ｂ）に示したように、アプリ設定ファイル５０２に宣言（あるいは記述）されているので、Ｓ８０１ではその値を読み取る。
そして、アプリケーション管理フレームワーク３０３は、起動済みアプリケーションのアプリケーション設定ファイル５０２又は５２０から、起動済みアプリケーションの使用ＦＤ数を取得する。複数のアプリケーションが起動済みの場合は、各アプリケーションの使用ＦＤ数を取得し、それらの総計を取得する（Ｓ８０２）。
そして、ステップＳ８０１で取得したＦＤ数と、ステップＳ８０２で取得したＦＤ数との合計数と、アプリケーション実行基盤３０１に定義されているシステムの総ＦＤ数とを比較する（Ｓ８０３）。比較により、Ｓ８０１とＳ８０２で取得したＦＤ数の合計数がシステムの総ＦＤ数を超えないと判定した場合、アプリ管理フレームワークはアプリケーション実行基盤３０１に、起動対象アプリケーションの開始を指示する。すなわち、起動対象アプリケーションが使用するライブラリをロードしても、その時点での使用済みＦＤ数がシステムで使用できるＦＤ数を超えないと判断できるなら、起動対象アプリケーションをそのまま起動する。アプリケーション実行基盤３０１は、クラスローダー３０２を通して、該アプリケーションの実行ファイルとアプリケーション内包ライブラリをロードする。そして、該アプリケーションの実行を開始して（Ｓ８１２）本フローチャートを終了する。なおステップＳ８０３では、ステップＳ８０１およびＳ８０２で取得したＦＤ数の合計からシステムの総ＦＤ数を差し引いた値（超過数）が０より大きいか否かを判定していると言い換えることもできる。

一方、ステップＳ８０３の比較により、Ｓ８０２とＳ８０３で取得したＦＤ数の合計数がシステムの総ＦＤ数を超えると判定した場合、システムで使用可能な総ＦＤ数に必要な空きがなく、起動対象アプリケーションが即時に起動できない。その場合、アプリケーション管理フレームワーク３０３は、起動中のアプリケーションの内包ライブラリのロードに使用しているＦＤ数を集計する（Ｓ８０４）。ＦＤはクラスローダー３０２がクラスをロードする際に使用されている。クラスをロードする際には、クラスを含むライブラリの読み込みが行われ、読み込みの際にＦＤが一つ使用される。アプリケーション実行基盤３０１がライブラリを読み込むと、システムとして終了するまでライブラリは読み込み状態となり、一つのＦＤが使用され続ける。そこでアプリケーション管理フレームワーク３０３は、起動済みアプリケーションのアプリケーション設定ファイル５０２のアプリクラスパスに記載されているライブラリ数を取得する。そして、取得したライブラリ数をライブラリのロードに使用しているＦＤ数として取得する（Ｓ８０４）。Ｓ８０４では、起動済みアプリケーションが複数あれば、各アプリケーションのアプリケーション設定ファイル５０２又は５２０から、使用しているＦＤ数を集計する。

次に、アプリケーション管理フレームワーク３０３は、起動対象アプリケーションのアプリケーション設定ファイル５０２から、起動対象アプリケーションのライブラリのロードに使用するＦＤ数を取得する（Ｓ８０５）。これもＳ８０４と同様、起動対象アプリケーションのアプリケーション設定ファイル５０２に記載されたアプリクラスパスに記載されているライブラリ数をＦＤ数として取得できる。

そして、アプリケーション管理フレームワーク３０３は、システムの総ＦＤ数と、ステップＳ８０１およびＳ８０２で取得した、アプリケーションにより使用中及び使用予定のＦＤ数の総計との差分を求める。すなわち、起動対象アプリケーションをこのまま起動したとしたら、システム上限を超過するであろうＦＤの数（超過数）を求める。そして、ステップＳ８０４及びステップＳ８０５にて集計した、各アプリケーションがクラスのロードのために使用するＦＤの数の合計と、前記計測した差分（すなわち超過数）とを比較する。ここで、ステップＳ８０４及びステップＳ８０５にて集計した、各アプリケーションがクラスのロードのために使用するＦＤの数の合計は、ライブラリを統合することで減らすことができるＦＤ数でもある。この減らすことができるＦＤ数が前述のＦＤの超過数より少ないと、ライブラリを統合したとしても、アプリケーションにより宣言されたＦＤ数の総計は、システムにおけるＦＤ上限値を超えることになる。そこで、比較の結果、クラスロードのために使用するＦＤ数よりも、ＦＤの超過数が多いと判定した場合は、アプリケーションが使用するライブラリを統合したとしても、アプリケーションで使用されるＦＤの数が足りないと判断する。そして、アプリケーション管理フレームワーク３０３が該アプリケーションの起動処理を行わず（Ｓ８１１）、本フローチャートを終了する。

一方、ステップＳ８０６の比較の結果、クラスロードのために使用するＦＤ数よりも、ＦＤの超過数の方が少ないと判定した場合は、使用しているＦＤ数をライブラリの統合により削減すれば、起動対象アプリケーションの起動が可能な状態となると判断できる。すなわち、ライブラリを統合することで、アプリケーションがライブラリをロードするために使用されるＦＤ数は、システム上限以内に収まる。そこでアプリケーション管理フレームワーク３０３は、ライブライ管理モジュール３０４に対して、全アプリケーションのアプリケーション内包ライブラリの統合処理を指示し、ステップＳ８０７へ進む。

統合処理の指示を受信したライブラリ管理モジュール３０４は、アプリケーション管理フレームワーク３０３が管理しているアプリケーションのリストの順に、ライブラリの統合処理を進める（Ｓ８０７）。統合処理としては、まず、起動オプション設定ファイル４００に記載されているクラスパスを参照し、クラスパスに記載されているライブラリを、動作に影響しない場所に解凍する。そして、次に全アプリケーションのアプリケーション設定ファイル５０２に記載されているアプリクラスパスを参照し、前述と同様に動作に影響しない場所に、アプリクラスパスに記載されているライブラリをすべて解凍する。ここでは、動作に影響しない場所に対して、統合ライブラリのベースとなるパスを定める。そして、ライブラリの解凍処理を行い、含まれるクラスを統合ライブラリのベースとなるパスにコピーする。解凍処理を行ったライブラリのクラスをコピーした後は、ライブラリのクローズ処理を行う。ライブラリの解凍処理のために使用するＦＤは、アプリケーション実行基盤３０１のライブラリ読み込みと異なり、ライブラリのクローズ処理によって解放される。アプリケーション管理フレームワーク３０３が管理するアプリケーションのリストの順に、対象となるライブラリを遂次処理することで、統合処理を行い際のＦＤの使用数を限定的にする。そして、起動中アプリケーションのクラスパスに記載されているライブラリと、アプリクラスパスに記載されているライブラリの解凍が全て完了したら、統合ライブラリのベースとなるパスを基準に、ＪＡＲ形式に再圧縮し、統合ライブラリを生成する。

そして、次にライブラリ管理モジュールは、統合したライブラリを対象としたアプリケーション設定ファイルを生成する（Ｓ８０８）。このアプリケーション設定ファイルには、統合ライブラリが、統合前のライブラリに代えてクラスパスに記載されているファイルとなる。ライブラリ管理モジュール３０４がライブラリの統合処理を完了すると、アプリケーション管理フレームワーク３０３は、統合ライブラリを管理対象とする。

そして、アプリケーション管理フレームワーク３０３は、画像形成装置１００の再起動が行われた際に、既存のライブラリが統合ライブラリに置き換わるように設定する（Ｓ８０９）。ここでは、統合ライブラリを既存のライブラリが配置されているパスと同様の箇所に配置する。そして、既存のクラスパス及びアプリクラスパスに記載されているライブラリを統合ライブラリに置き換えた起動オプション設定ファイル及び統合ライブラリ用のアプリケーション設定ファイルを、起動時に差し替えるよう起動モジュール３００に指示する。

そして、画像形成装置１００を再起動させ、画像形成装置１００の再起動が行われた後で、統合ライブラリの起動処理を行い、起動対象アプリケーションの起動を行い（Ｓ８１０）、本フローチャートを終了する。

本実施例のステップＳ８０７以降で示すように、ライブラリ管理モジュール３０４が統合ライブラリを生成し、その統合ライブライをアプリ設定ファイルのアプリクラスパスに設定する。これにより、アプリケーション実行基盤３０１が該アプリケーションのクラスをロードする際に、クラスローダー３０２は統合ライブラリのみを探索することで、該当クラスを見つけることが可能となる。アプリケーションに複数の内包ライブラリが存在する場合に比べて、ファイルディスクリプタの消費を１に抑えることが可能となる。

また、前述の統合ライブラリの生成処理を、アプリケーションの実行開始前に行うことで、画像形成装置１００のリソース容量が確保される場合は、画像形成装置の起動処理に影響を与えることなく、ファイルディスクリプタの消費を抑えることが出来る。
さらに、画像形成装置１００のリソース容量が確保できずアプリケーションの即時開始が困難な場合でも、画像形成装置内の全てのアプリケーションの統合ライブラリを生成することで、ファイルディスクリプタの消費を抑えることが可能となる。この場合、本実施例では画像形成装置の再起動を必要としているが、インストールしたアプリケーションの実行できないといった現象を回避する方法があることも示すことが出来ている。

なお、ステップＳ８０１で取得したＦＤ数が０の場合には、Ｓ８０３ではＦＤ数の合計がシステムの総数より大きくなることはないので、Ｓ８０１の直後に取得したＦＤ数が０であるか判定し、０であればＳ８１２に分岐してもよい。

［実施例２］
本発明における二つ目の実施例について、図９のフローチャートを用いて説明する。本実施例は、図８のフローチャート同様に、アプリケーション管理フレームワーク３０３がアプリケーションのインストールを行い、アプリケーション管理フレームワーク３０３が管理者ユーザーからのリクエストを受信、もしくは自動的にアプリケーションの起動を行うところから開始する。そして、図８のステップＳ８０１〜Ｓ８０３で同様の処理を行い、ステップＳ８０３の判定により、ＦＤの該合計数が該システムの総ＦＤ数を超えないと判定した際に、ステップＳ９１３へと進む。

ステップＳ９１３では、アプリケーション管理フレームワーク３０３が、起動対象アプリケーションのアプリケーション設定ファイルから、複数のアプリクラスパスが登録されているか否かを判定する。アプリクラスパスの記載が一つ、もしくは、存在しない場合にＳ８１２へ進み、前述と同様に該アプリケーションの起動処理を行う。

アプリクラスパスに、二つ以上のライブラリが記載されている場合、アプリケーション管理フレームワーク３０３は、ライブラリ管理モジュール３０４に対して、該アプリケーションの統合ライブラリ生成を指示する。

統合ライブラリ生成の指示を受信したライブラリ管理モジュール３０４は、起動するアプリケーションに含まれるライブラリを解凍し、再圧縮を行い、統合ライブラリを生成する（Ｓ９１４）。そして、起動するアプリケーションのアプリケーション設定ファイルのアプリクラスパスの記載を、統合ライブラリのみの記載に変更し、統合ライブラリを生成する。アプリケーション管理フレームワークは、アプリケーション実行基盤３０１に対して、該生成した統合ライブラリを実行するように指示する。
そして、アプリケーション実行基盤３０１は、クラスローダー３０２を通して生成した統合ライブラリをロードし、該アプリケーションを起動し（Ｓ９１５）、本フローチャートを終了する。

このようにＦＤ数の不足が発生しない場合でも、アプリケーション内に複数ライブラリが含まれるか否かを判定し、複数のライブラリが含まれる場合には該アプリケーションのみを対象とした統合ライブラリを生成することで、ＦＤの使用数を削減することが可能となる。

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

１００ 画像形成装置、１０１ 管理用情報処理装置、１３０ ネットワーク、３０２ アプリケーション管理フレームワーク、３０４ リソースサービス、４０２ リソース宣言ファイル、４１２ リソース上限値、４１３ 使用リソース初期値

Claims (13)

1. 開いたライブラリの数に応じた量のリソースを消費する情報処理装置であって、
   インストールされた起動対象プログラムを起動する前に、該起動対象プログラムと起動済みのプログラムとについて設定されたリソースの上限値の合計から、前記情報処理装置で利用できるリソースの総数を差し引いた超過数が０より大きいか判定する第１の判定手段と、
   前記第１の判定手段により大きいと判定された場合には、前記超過数が、前記起動対象プログラムと前記起動済みのプログラムとにより使用されるライブラリの数の合計よりも少ないか判定する第２の判定手段と、
   前記第２の判定手段により少ないと判定された場合には、前記起動対象プログラムと前記起動済みのプログラムとにより使用されるライブラリに含まれたクラスを統合ライブラリに統合する統合手段と
   を有することを特徴とする情報処理装置。
2. 前記ライブラリは、１つ以上のクラスを圧縮したファイルであり、
   前記統合手段は、前記ライブラリを解凍し、前記統合ライブラリに統合して圧縮することを特徴とする請求項１に記載の情報処理装置。
3. 前記統合手段によるクラスの統合の後に、前記情報処理装置を再起動することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記第１の判定手段により、前記超過数が０より大きくないと判定された場合には、前記起動対象プログラムをそのまま起動することを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
5. 前記起動対象プログラムについて設定されたリソースの上限値が０の場合には、前記起動対象プログラムをそのまま起動することを特徴とする請求項１乃至４のいずれか一項に記載の情報処理装置。
6. 前記起動対象プログラムを実行する際に、該プログラムで用いられるクラスを含むライブラリを開いて当該クラスをロードするロード手段を更に有することを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 前記第１の判定手段により、前記超過数が０より大きくないと判定された場合に、前記起動対象プログラムにより使用されるライブラリの数が複数であるか判定する第３の判定手段を更に有し、
   前記統合手段は、前記第３の判定手段により複数であると判定された場合にも、前記起動対象プログラムと前記起動済みのプログラムとにより使用されるライブラリに含まれたクラスを統合し、複数でないと判定された場合には、前記起動対象プログラムをそのまま起動することを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
8. 前記第２の判定手段によりは、前記起動対象プログラムと前記起動済みのプログラムとにより使用されるライブラリの数を、前記起動対象プログラムと前記起動済みプログラムのそれぞれの設定ファイルに記述された、ライブラリの所在を示すクラスパスに基づいて特定することを特徴とする請求項１乃至７のいずれか一項に記載の情報処理装置。
9. 前記リソースにはファイルディスクリプタが含まれることを特徴とする請求項１乃至８のいずれか一項に記載の情報処理装置。
10. 開いたライブラリの数に応じた量のリソースを消費する情報処理装置によるライブラリ管理方法であって、
    インストールされた起動対象プログラムを起動する前に、該起動対象プログラムと起動済みのプログラムとについて設定されたリソースの上限値の合計から、前記情報処理装置で利用できるリソースの総数を差し引いた超過数が０より大きいか判定する第１の判定工程と、
    前記第１の判定工程により大きいと判定された場合には、前記超過数が、前記起動対象プログラムと前記起動済みのプログラムとにより使用されるライブラリの数の合計よりも少ないか判定する第２の判定工程と、
    前記第２の判定工程により少ないと判定された場合には、前記起動対象プログラムと前記起動済みのプログラムとにより使用されるライブラリに含まれたクラスを統合ライブラリに統合する統合工程と
    を有することを特徴とするリソース管理方法。
11. 前記ライブラリは、１つ以上のクラスを圧縮したファイルであり、
    前記統合工程では、前記ライブラリを解凍し、前記統合ライブラリに統合して圧縮することを特徴とする請求項１０に記載のリソース管理方法。
12. 開いたライブラリの数に応じた量のリソースを消費するコンピューターを、
    インストールされた起動対象プログラムを起動する前に、該起動対象プログラムと起動済みのプログラムとについて設定されたリソースの上限値の合計から、前記コンピューターで利用できるリソースの総数を差し引いた超過数が０より大きいか判定する第１の判定手段と、
    前記第１の判定手段により大きいと判定された場合には、前記超過数が、前記起動対象プログラムと前記起動済みのプログラムとにより使用されるライブラリの数の合計よりも少ないか判定する第２の判定手段と、
    前記第２の判定手段により少ないと判定された場合には、前記起動対象プログラムと前記起動済みのプログラムとにより使用されるライブラリに含まれたクラスを統合ライブラリに統合する統合手段と
    して機能させるためのプログラム。
13. 前記ライブラリは、１つ以上のクラスを圧縮したファイルであり、
    前記統合手段は、前記ライブラリを解凍し、前記統合ライブラリに統合して圧縮することを特徴とする請求項１２に記載のプログラム。

Images