JP2009070208A - 画像処理装置およびメモリ確保方法 - Google Patents

Abstract

【課題】メモリの使用効率を改善する画像処理装置およびメモリ確保方法を提供すること。
【解決手段】データを記憶する物理メモリと、搭載可能な物理メモリの容量と、アプリケーションおよび制御手段の少なくとも一方が管理する仮想メモリ領域にマッピングする物理メモリ内の領域である直接マップ領域の容量とを対応づけた容量情報を保持する保持部１２１ａと、保持された容量情報から、搭載されている物理メモリの容量に対応する直接マップ領域の容量を取得する取得部１２１ｂと、取得された容量の直接マップ領域を、搭載されている物理メモリ内に確保する確保部１２１ｃと、を備えた。
【選択図】 図１

Description

この発明は、プロセスが直接マッピングするメモリ領域を確保する画像処理装置およびメモリ確保方法に関するものである。

近年、プリンタ、コピー、ファクシミリ、スキャナなどの各装置の機能を１つの筐体内に収納した画像処理装置が一般的に知られている。このような複合型の画像処理装置は、１つの筐体内に表示部、印刷部および撮像部などを設けるとともに、プリンタ、コピーおよびファクシミリ装置にそれぞれ対応する３種類のアプリケーションを設け、アプリケーションの切替えによって、当該装置をプリンタ、コピー、スキャナまたはファクシミリ装置として動作させる。

このような従来の複合型の画像処理装置は、プリンタ、コピーおよびファクシミリにそれぞれ対応する別個のアプリケーション（ＯＳ（オペレーティングシステム）を含む）を備えている。そして、通常、各アプリケーションを実行して生成されるプロセスが必要とするメモリはそれぞれ別個に獲得され、また、個別に管理される。

一方、このような複合型の画像処理装置では、例えば、読込んだ画像データをコピーすると同時にファクシミリ送信する場合のように、同一のデータを複数のアプリケーションのプロセスで利用する場合がある。このため、各アプリケーションのプロセスで共通の画像データ等を利用可能とするためのさまざまなメモリ管理技術が提案されている。

例えば、特許文献１では、画像形成処理を行うアプリケーションのプロセス等によって直接マップ可能な直接マップ領域を獲得する技術が提案されている。これにより、多種の画像処理機能それぞれに対応するアプリケーションのプロセス間でのデータの共有が可能となる。

また、例えば、特許文献２では、直接マップ領域用の物理アドレスと、直接マップ領域用の仮想アドレスとを対応づけておくことにより、アドレス変換時の例外エラーの発生を減少させ、直接マップ領域に対するメモリアクセスのオーバーヘッドを軽減する技術が提案されている。この方法では、連続する仮想アドレスを連続する物理アドレスに割り当てるため、ダイレクト・メモリ・アクセスを利用した場合のメモリアクセスの際に発生するオーバーヘッドを軽減しつつ、メモリの使用効率を向上させることができる。

昨今では、ユーザの使用形態に応じて画像処理装置の機器構成を変更可能とすることが求められている。このため、例えば、画像処理装置に搭載されるメモリのメモリサイズが使用形態によってそれぞれ異なる場合がある。また、搭載されるアプリケーション構成を動的に変更するシステムも存在する。さらに、アプリケーションの機能拡張・規模増大に伴い、使用するメモリサイズも増大化の傾向にある。

特開２００３−３３７７１４号公報 特開２００３−３１６６４６号公報

しかしながら、特許文献１および２の方法では、直接マップ領域のサイズとして事前に定められた固定サイズを割り当てるため、画像処理装置の使用形態によってはメモリの使用効率が悪化する場合があった。例えば、利用されるアプリケーションに対して十分なメモリサイズのメモリを搭載しているにもかかわらず、直接マップ領域に割り当てられるメモリサイズが過大であるため、実際にアプリケーションが利用可能なメモリサイズが不足する場合があった。

本発明は、上記に鑑みてなされたものであって、装置に搭載されるメモリのサイズに応じて特定プロセス用に割り当てるメモリ領域のサイズを変更可能とすることにより、メモリの使用効率を改善することができる画像処理装置およびメモリ確保方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、ハードウェア資源を利用した画像処理にかかるアプリケーションと、オペレーティングシステムと、前記オペレーティングシステム上で動作し、複数の前記アプリケーションからアクセスされて前記ハードウェア資源の制御を行う制御手段とを備えた画像処理装置であって、データを記憶する物理メモリと、搭載可能な前記物理メモリの容量と、前記アプリケーションおよび前記制御手段の少なくとも一方が管理する仮想メモリ領域にマッピングする前記物理メモリ内の領域である直接マップ領域の容量とを対応づけた容量情報を保持する保持手段と、前記保持手段に保持された前記容量情報から、搭載されている前記物理メモリの容量に対応する前記直接マップ領域の容量を取得する取得手段と、取得された前記容量の前記直接マップ領域を、搭載されている前記物理メモリ内に確保する確保手段と、を備えたことを特徴とする。

また、請求項２にかかる発明は、請求項１にかかる発明において、前記保持手段は、複数の異なる前記容量情報と、前記容量情報のそれぞれを識別する識別子とを対応づけて保持し、複数の前記容量情報のうち、指定された前記容量情報の前記識別子を記憶する識別子記憶手段をさらに備え、前記取得手段は、前記識別子記憶手段に記憶されている前記識別子に対応する前記容量情報から、搭載されている前記物理メモリの容量に対応する前記直接マップ領域の容量を取得すること、を特徴とする。

また、請求項３にかかる発明は、請求項２にかかる発明において、前記識別子記憶手段に記憶されている前記識別子を、ユーザの指定に応じて他の前記識別子に変更する変更手段をさらに備えたこと、を特徴とする。

また、請求項４にかかる発明は、請求項１にかかる発明において、前記確保手段は、搭載されている前記物理メモリの予め定められたアドレスを先頭アドレスとして、取得した前記容量の前記直接マップ領域を、搭載されている前記物理メモリ内に確保すること、を特徴とする。

また、請求項５にかかる発明は、請求項１にかかる発明において、前記確保手段は、前記物理メモリ内の前記直接マップ領域以外の領域に、前記オペレーティングシステムが管理する仮想メモリ領域にマッピングする前記物理メモリ内の領域である汎用領域を確保すること、を特徴とする。

また、請求項６にかかる発明は、ハードウェア資源を利用した画像処理にかかるアプリケーションと、オペレーティングシステムと、前記オペレーティングシステム上で動作し、複数の前記アプリケーションからアクセスされて前記ハードウェア資源の制御を行う制御手段とを備えた画像処理装置で行われるメモリ確保方法であって、前記画像処理装置は、データを記憶する物理メモリと、搭載可能な前記物理メモリの容量と、前記アプリケーションおよび前記制御手段の少なくとも一方が管理する仮想メモリ領域にマッピングする前記物理メモリ内の領域である直接マップ領域の容量とを対応づけた容量情報を保持する保持手段と、を備え、取得手段が、前記保持手段に保持された前記容量情報から、搭載されている前記物理メモリの容量に対応する前記直接マップ領域の容量を取得する取得ステップと、確保手段が、取得された前記容量の前記直接マップ領域を、搭載されている前記物理メモリ内に確保する確保ステップと、を備えたことを特徴とする。

本発明によれば、装置に搭載されるメモリのサイズに応じて特定プロセス用に割り当てるメモリ領域のサイズを変更可能とすることにより、メモリの使用効率を改善することができるという効果を奏する。

また、本発明によれば、搭載メモリサイズに応じて特定プロセス用に割り当てるメモリ領域のサイズを、複数のサイズの候補から指定可能とすることにより、使用形態に応じてメモリの使用効率をさらに改善することができるという効果を奏する。

以下に添付図面を参照して、この発明にかかる画像処理装置およびメモリ確保方法の最良な実施の形態を詳細に説明する。

（第１の実施の形態）
第１の実施の形態にかかる画像処理装置は、搭載されているメモリの容量に応じて、プロセスが直接マッピング可能な領域である直接マップ領域の容量を変更するものである。

以下では、一実施の形態として、画像処理装置であってコピー機能、ファクシミリ（ＦＡＸ）機能、プリント機能、スキャナ機能及び入力画像（スキャナ機能による読み取り原稿画像やプリンタあるいはＦＡＸ機能により入力された画像）を配信する機能等を融合したいわゆるＭＦＰ（Multi Function Peripheral）と称される融合機１００に適用した例を示す。

図１は、第１の実施の形態にかかる融合機１００の機能ブロック図である。図１に示すように、融合機１００は、ハードウェア資源１０５と、ソフトウェア群１１０と、融合機起動部１４０とを含むように構成される。

ハードウェア資源１０５は、白黒レーザプリンタ（Ｂ＆Ｗ ＬＰ）１０１と、カラーレーザプリンタ（Ｃｏｌｏｒ ＬＰ）１０２と、スキャナ、ファクシミリなどのその他ハードウェアリソース１０３などを有する。

また、ソフトウェア群１１０は、ＵＮＩＸ（登録商標）などのオペレーティングシステム（以下、ＯＳという）１２１上に起動されているプラットフォーム１２０とアプリケーション１３０とから構成される。

融合機起動部１４０は、融合機１００の電源投入時に先ず始めに実行され、プラットフォーム１２０やアプリケーション１３０を起動する。プラットフォーム１２０は、アプリケーション１３０からの処理要求を解釈して、ハードウェア資源の獲得要求を発生させる制御部である下記に示すコントロールサービス１５０と、一または複数のハードウェア資源の管理をおこない、コントロールサービス１５０からの獲得要求を調停するシステムリソースマネージャー（ＳＲＭ（System Resource Manager）１２３）と、ＳＲＭ１２３からの獲得要求に応じてハードウェア資源１０５の管理を行うハンドラ層１６０とを有する。

このコントロールサービス１５０は、複数のサービスモジュールにより形成され、具体的には、ＳＣＳ（System Control Service）１２２と、ＥＣＳ（(Engine Control Service)１２４と、ＭＣＳ（Memory Control Service）１２５と、ＯＣＳ（Operationpanel Control Service）１２６と、ＦＣＳ（FAX Control Service）１２７と、ＮＣＳ（Network ControlService）１２８とがある。なお、このプラットフォーム１２０は、あらかじめ定義された関数により前記アプリケーション１３０からの処理要求を受信可能とするアプリケーションプログラムインターフェース（ＡＰＩ）１１５を有する。

ＯＳ１２１は、ＵＮＩＸ（登録商標）などのオペレーティングシステムであり、プラットフォーム１２０並びにアプリケーション１３０の各ソフトウェアをそれぞれプロセスとして並列実行する。オープンソースのＵＮＩＸ（登録商標）を用いることにより、プログラムの安全性を確保できるとともに、ネットワーク対応可能となり、ソースコードの入手も容易となる。さらに、ＯＳ、ＴＣＰ／ＩＰのロイヤリティが不要であり、アウトソーシングも容易となる。

ＯＳ１２１は、保持部１２１ａと、取得部１２１ｂと、確保部１２１ｃと、を備えている。保持部１２１ａは、搭載可能なメモリの容量と、直接マップ領域の容量とを対応づけた容量情報を保持するものである。図２は、第１の実施の形態の容量情報のデータ構造の一例を示す説明図である。図２に示すように、容量情報は、搭載メモリサイズと、直接マップ領域サイズとを含んでいる。同図では、例えば搭載メモリサイズが１２８ＭＢ（メガバイト）のときは、直接マップ領域として１２ＭＢを確保することを意味する容量情報の例が示されている。

取得部１２１ｂは、搭載されているメモリのメモリサイズを取得するとともに、取得したメモリサイズに対応する直接マップ領域サイズを、容量情報を参照して取得するものである。確保部１２１ｃは、取得部１２１ｂによって取得されたサイズの直接マップ領域を、メモリ内に確保するものである。また、確保部１２１ｃは、物理メモリ内の直接マップ領域以外の領域を対象として、汎用的に管理される汎用領域を物理メモリ内に確保する。

ＳＲＭ１２３は、ＳＣＳ１２２とともにシステムの制御およびリソースの管理をおこなうものであり、スキャナやプロッタなどのエンジン部、メモリ、ＨＤＤファイル、ホストＩ／Ｏ（セントロＩ／Ｆ、ネットワークＩ／Ｆ、ＩＥＥＥ１３９４Ｉ／Ｆ、ＲＳ２３２ＣＩ／Ｆなど）のハードウェア資源を利用する上位層からの要求にしたがって調停をおこない、実行制御する。具体的には、このＳＲＭ１２３は、要求されたハードウェア資源が利用可能であるかどうか（他の要求により利用されていないかどうか）を判断し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に伝える。また、上位層からの要求に対してハードウェア資源の利用スケジューリングをおこない、要求内容（たとえば、プリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成など）を直接実施するようにしてもよい。

ＳＣＳ１２２は、アプリ管理（機能１）、操作部制御（機能２）、システム画面表示（ジョブリスト画面、カウンタ表示画面など）（機能３）、ＬＥＤ表示（機能４）、リソース管理（機能５）、割り込みアプリ制御（機能６）等の複数の機能を行なう。

具体的には、アプリ管理（機能１）では、アプリの登録と、その情報を他のアプリに通知する処理をおこなう。操作部制御（機能２）では、アプリの操作部使用権の排他制御をおこなう。システム画面表示（機能３）では、操作部使用権を持つアプリからの要求内容に応じて、エンジン部の状態に対応する警告画面の表示をおこなう。ＬＥＤ表示（機能４）では、警告ＬＥＤ、アプリキーなどのシステムＬＥＤの表示制御をおこなう。リソース管理（機能５）では、アプリ（ＥＣＳ）がジョブを実行するにあたって、排他しなければならないエンジンリソース（スキャナ、ステープルなど）の排他制御のためのサービスをおこなう。割り込みアプリ制御（機能６）では、特定のアプリを優先動作させるための制御及びサービスをおこなう。

ＥＣＳ１２４は、白黒レーザプリンタ（Ｂ＆Ｗ ＬＰ）１０１、カラーレーザプリンタ（Ｃｏｌｏｒ ＬＰ）１０２、その他ハードウェアリソース１０３などのエンジン部を制御するものであり、画像読み込みと印刷動作、状態通知、ジャムリカバリなどをおこなう。

ＭＣＳ１２５は、メモリ制御をおこなうものであり、具体的には、画像メモリの取得および開放、ハードディスク装置（ＨＤＤ）の利用、画像データの圧縮および伸張などをおこなう。

ＯＣＳ１２６は、オペレータと本体制御間の情報伝達手段となる操作パネルを制御するモジュールであり、オペレータのキー操作イベントを本体制御に通知する処理、各アプリがＧＵＩを構築するためのライブラリ関数を提供する処理、構築されたＧＵＩ情報をアプリ別に管理する処理、操作パネル上への表示反映処理などをおこなう。

ＦＣＳ１２７は、システムコントローラの各アプリ層からＰＳＴＮ／ＩＳＤＮ網を使ったファクシミリ送受信、ＢＫＭ（バックアップＳＲＡＭ）で管理されている各種ファクシミリデータの登録／引用、ファクシミリ読み取り、ファクシミリ受信印刷、融合送受信をおこなうためのＡＰＩ（Application Program Interface）を提供する。

ＮＣＳ１２８は、ネットワークＩ／Ｏを必要とするアプリケーションに対して共通に利用できるサービスを提供するためのモジュール群であり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからデータをネットワーク側に送信する際の仲介をおこなう。

また、ハンドラ層１６０は、後述するＦＣＵ（FAX Control Unit）の管理を行うＦＣＵＨ（FAX Control Unit Handler）１３１と、各プロセスに対するメモリの割り振り、各プロセスに割り振ったメモリの管理、直接マップ領域の管理などを行うＩＭＨ（Imaging Memory Handler）１２９とを含む。また、ＩＭＨ１２９はイメージデータを仮想メモリ領域（ユーザ仮想空間）から物理メモリへマップする。プロセスの起動に応じて、システムコールを行ない、プロセス用の仮想メモリ領域をマップしたり、マップした仮想メモリ領域をプロセスの終了時に開放する処理等を行なう。ＩＭＨ１２９は、後述されるＣＰＵによって直接アクセス可能なＭＥＭ−Ｐ領域と、プロセスによって直接アクセス可能なＭＥＭ−Ｐ０領域へのマップを行なう。

ＳＲＭ１２３、ＦＣＵＨ１３１およびＩＭＨ１２９は、予め定義されている関数によりハードウェア資源１０５に対する処理要求を送信するエンジンＩ／Ｆ１３３を利用してハードウェア資源１０５に対する処理要求を行う。

アプリケーション１３０は、ページ記述言語（ＰＤＬ）、ＰＣＬおよびポストスクリプト（ＰＳ）を有するプリンタ用のアプリケーションであるプリンタアプリ１１１と、コピー用アプリケーションであるコピーアプリ１１２と、ファクシミリ用アプリケーションであるファックスアプリ１１３と、スキャナ用アプリケーションであるスキャナアプリ１１４とを有する。各アプリケーション１１１〜１１４は、プラットフォーム１２０上の各プロセスを利用して動作実行し得るため、画面制御、キー操作制御およびジョブ生成などをおこなう画面表示制御プログラムがその主体となる。なお、ＮＣＳ１２８により接続されたネットワークを介して新たなアプリケーションをネットワーク経由で搭載することもできる。また、各アプリケーションはアプリケーションごとに追加または削除することができる。

このように、融合機１００は、各アプリで共通的に必要となる処理をプラットフォーム１２０で一元的に処理する。

次に、融合機１００のハードウェア構成について説明する。図３は、図１に示した融合機１００のハードウェア構成を示すブロック図である。図３に示すように、この融合機１００は、オペレーションパネル３１０、ファックスコントロールユニット（ＦＣＵ）３２０、ＵＳＢ（Universal Serial Bus）デバイス３３０、ＩＥＥＥ１３９４デバイス３４０およびエンジン部３５０とコントローラ３００のＡＳＩＣ３０１とをＰＣＩ（Peripheral Component Interconnect）バス等で接続した構成となる。

コントローラ３００は、ＡＳＩＣ３０１にＭＥＭ−Ｃ３０２、ＨＤ３０３、ネットワークＩ／Ｆコントローラ３０９などを接続するとともに、このＡＳＩＣ３０１とＣＰＵ３０４とをＣＰＵチップセットのＮＢ３０５を介して接続している。このように、ＮＢ３０５を介して接続する理由は、ＣＰＵ３０４自体のインターフェースが公開されていないためである。ここで、このＡＳＩＣ３０１とＮＢ３０５は、単にＰＣＩを介して接続されているのではなく、ＡＧＰ３０８を介して接続されている。このようにＡＧＰ３０８を介して接続することとした理由は、この融合機１００が図１に示したプラットフォーム１２０やアプリケーション１３０を形成する複数のプロセスを実行制御する関係上、これらを低速のＰＣＩで接続したのでは、パフォーマンスが低下するからである。

ＣＰＵ３０４は、融合機１００の全体制御をおこなうものであり、具体的には、ＯＳ１２１上でプラットフォーム１２０を形成するＳＣＳ１２２、ＳＲＭ１２３、ＥＣＳ１２４、ＭＣＳ１２５、ＯＣＳ１２６、ＦＣＳ１２７、ＮＣＳ１２８をそれぞれプロセスとして起動して実行させるとともに、アプリケーション１３０を形成するプリンタアプリ１１１、コピーアプリ１１２、ファックスアプリ１１３、スキャナアプリ１１４を起動して実行させる。

ＮＢ３０５は、ＣＰＵ３０４とＭＥＭ−Ｐ３０６ａ、ＮＶ−ＲＡＭ３０６ｂ、ＳＢ３０７、ＡＳＩＣ３０１とを接続するためのブリッジである。

ＭＥＭ−Ｐ３０６ａは、融合機１００の描画用メモリなどとして用いるシステムメモリであり、ＮＶ−ＲＡＭ３０６ｂは、電源断時でもデータが消えない不揮発メモリであり、ＳＢ３０７は、ＮＢ３０５とＲＯＭ、ＰＣＩデバイス、周辺デバイスとを接続するためのブリッジである。ＭＥＭ−Ｃ３０２は、コピー用画像バッファ、符号バッファとして用いるローカルメモリであり、ＡＳＩＣ３０１は、画像処理用のハードウェア要素を有する画像処理用途向けのＩＣである。

ＨＤＤ３０３は、画像データの蓄積、プログラムの蓄積、フォントデータの蓄積、フォームの蓄積を行うためのストレージであり、オペレーションパネル３１０は、操作者からの入力操作の受け付け並びに操作者に向けた表示をおこなう操作部である。

したがって、ＡＳＩＣ３０１には、ＭＥＭ−Ｃ３０２を接続するためのＲＡＭインターフェースと、ＨＤＤ３０３を接続するためのハードディスクインターフェースが設けられ、これらの記憶部に対して画像データの入出力をおこなう場合には、入出力先がＲＡＭインターフェースまたはハードディスクインターフェースに切り替えられる。

ＡＧＰ３０８は、グラフィック処理を高速化するために提案されたグラフィックスアクセラレーターカード用のバスインターフェースであり、システムメモリに高スループットで直接アクセスすることにより、グラフィックスアクセラレーターカードを高速にする。

ＵＮＩＸ（登録商標）等のＯＳ１２１上にプラットフォーム１２０及びアプリケーション１３０が構築される融合機１００の場合、仮想メモリ領域は、ＯＳ１２１のカーネルによって解釈可能な仮想アドレス空間と、ソフトウェアによって生成されたプロセスによって解釈可能な仮想アドレス空間とによって制御されている。

そのため、ＯＳ１２１独自で仮想メモリ領域（以下、カーネル用仮想メモリ領域とする）へのアクセスを制御すると共に、ソフトウェアによって生成されたプロセスによって展開される仮想メモリ領域（以下、プロセス毎仮想メモリ領域とする）へのアクセスを制御する必要がある。また、ＯＳ１２１がカーネル用仮想メモリ領域からプロセス毎仮想メモリ領域をアクセスする際には、ＯＳ１２１からアクセス可能な仮想メモリ領域に変換される。

先ず、ＭＥＭ−Ｃ３０２、ＭＥＭ−Ｐ３０６ａ及びＨＤＤ３０３等にて展開される物理メモリと仮想メモリ領域との対応について図４で説明する。図４を参照すると、物理メモリ１０には、カーネルが使用するカーネル領域１１と、ＯＳ１２１で汎用的に管理される汎用領域１２と、ＭＥＭ−Ｐ３０６ａの領域の一部であって、アプリケーション１３０又はコントロールサービス１５０によって生成されるプロセスから仮想メモリ領域へマップされるＭＥＭ−Ｐ０領域１３と、ＣＰＵ３０４から高速にアクセスされるＭＥＭ−Ｐ３０６ａとしての実質的なＭＥＭ−Ｐ領域１４と、白黒レーザプリンタ（Ｂ＆Ｗ ＬＰ）１０１、カラーレーザプリンタ（Ｃｏｌｏｒ ＬＰ）１０２、その他ハードウェアリソース１０３がエンジンＩ／Ｆ１３３を介して高速にアクセス可能なＭＥＭ−Ｃ３０２としての実質的なＭＥＭ−Ｃ領域１５とを有する。

領域１１から領域１４は、ＭＥＭ−Ｐ３０６ａ側のＲＡＭが使用され、領域１５は、ＭＥＭ−Ｃ３０２側のＲＡＭが使用される。

この物理メモリ１０に対応させて展開される仮想メモリ領域２０は、ＯＳ１２１によって汎用的に管理されるユーザプログラム領域２１と、プロセスが該プロセスの仮想メモリ領域２０から物理メモリ１０へ直接マップ可能な直接マップ領域２２と、ＯＳ１２１によって汎用的に管理され必要に応じてデータがスタックされるスタック領域２３とを有する。

ユーザプログラム領域２１は、更に、アプリケーション１３０をＣＰＵ３０４が実行するためのプログラムコードを格納するプログラムコード領域２１１と、アプリケーション１３０をＣＰＵ３０４が実行する際に必要となるプログラムデータを格納するプログラムデータ領域２１２と、動的にデータ領域の割付けを行なうヒープ領域２１３とを有する。

ユーザプログラム領域２１は、物理メモリ１０の汎用領域１２にマップされる。スタック領域２３もまた、物理メモリ１０の汎用領域１２にマップされる。直接マップ領域２２は、ＭＥＭ−Ｐ３０６ａの一部と、ＭＥＭ−Ｃ３０２とに対応する領域である。直接マップ領域２２は、物理メモリ１０のＭＥＭ−Ｐ０領域１３、ＭＥＭ−Ｐ領域１４及びＭＥＭ−Ｃ領域１５とに夫々対応するＭＥＭ−Ｐ０領域２２１、ＭＥＭ−Ｐ領域２２２及びＭＥＭ−Ｃ領域２２３とを有する。

次に、このように構成された第１の実施の形態にかかる融合機１００によるメモリ確保処理について説明する。図５は、第１の実施の形態におけるメモリ確保処理の全体の流れを示すフローチャートである。

まず、取得部１２１ｂは、搭載可能なメモリの容量と直接マップ領域の容量とを対応づけた容量情報を保持部１２１ａから取得する（ステップＳ５０１）。なお、容量情報は、カーネルビルド時に読み込まれるビルド時の設定情報を保存したｃｏｎｆｉｇファイルから取込まれ、ビルドの結果生成されたＯＳ内の保持部１２１ａで保持される。

次に、取得部１２１ｂは、容量情報を取得できたか否かを判断する（ステップＳ５０２）。容量情報が取得できた場合（ステップＳ５０２：ＹＥＳ）、取得部１２１ｂは、搭載メモリサイズを取得するシステムコールなどによって、融合機１００に搭載されている物理メモリのメモリサイズを取得する（ステップＳ５０３）。

次に、取得部１２１ｂは、取得した物理メモリのメモリサイズに対応する直接マップ領域サイズを、容量情報から取得する（ステップＳ５０４）。例えば、物理メモリのメモリサイズとして１２８ＭＢを取得した場合は、取得部１２１ｂは、図２のような容量情報から、対応する直接マップ領域サイズとして１２ＭＢを取得する。

ステップＳ５０２で、容量情報が取得できなかった場合（ステップＳ５０２：ＮＯ）、取得部１２１ｂは、直接マップ領域サイズのデフォルト値を設定する（ステップＳ５０５）。これは、例えば、ｃｏｎｆｉｇファイル内に容量情報に対応する情報が設定されていなかった場合等が該当する。取得部１２１ｂは、例えば、直接マップ領域サイズのデフォルト値としてカーネルのソースコードに記載され、ビルドの結果生成されたＯＳ内に保持しているデフォルト値を取得する。

次に、取得部１２１ｂは、取得した直接マップ領域サイズが搭載されている物理メモリのメモリサイズ以下であるか否かを判断する（ステップＳ５０６）。直接マップ領域サイズが物理メモリのメモリサイズ以下の場合は（ステップＳ５０６：ＹＥＳ）、確保部１２１ｃは、直接マップ領域サイズ分の領域を物理メモリ内に直接マップ領域として確保する（ステップＳ５０７）。次に、確保部１２１ｃは、確保した直接マップ領域以外の領域を対象として、汎用領域を確保する（ステップＳ５０８）。

ステップＳ５０６で、取得した直接マップ領域サイズが搭載されている物理メモリのメモリサイズ以下でない場合は（ステップＳ５０６：ＮＯ）、直接マップ領域サイズの指定が不適切であるため、エラー処理を行ってメモリ確保処理を終了する（ステップＳ５０９）。

このように、第１の実施の形態にかかる画像処理装置では、搭載されているメモリの容量に応じて、プロセスが直接マッピング可能な直接マップ領域の容量を変更することができる。これにより、搭載するメモリのメモリサイズを変更した場合であっても、直接マップ領域を適切なサイズに変更できるため、メモリの使用効率を改善することが可能となる。

（第２の実施の形態）
第２の実施の形態にかかる画像処理装置は、搭載されているメモリの容量に応じた直接マップ領域の容量を、複数の容量の候補から指定可能とするものである。

図６は、第２の実施の形態にかかる融合機６００の機能ブロック図である。同図に示すように、融合機６００は、ハードウェア資源１０５と、ソフトウェア群６１０と、融合機起動部１４０とを含むように構成される。

第２の実施の形態では、ＯＳ６２１内の保持部６２１ａおよび取得部６２１ｂの構成と、ソフトウェア群６１０内にアプリケーション６３０の１つとして変更部６１６を追加したことと、が第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかる融合機１００の構成を表すブロック図である図１と同様であるので、同一符号を付し、ここでの説明は省略する。

保持部６２１ａは、複数の異なる容量情報を保持可能とした点が、第１の実施の形態の保持部１２１ａと異なっている。図７は、第２の実施の形態の容量情報のデータ構造の一例を示す説明図である。図７に示すように、第２の実施の形態の保持部６２１ａは、容量情報を識別する識別情報としてのフラグと、各容量情報とを対応づけて保持している。同図では、例えば、フラグ＝１および２の容量情報の例として、搭載メモリサイズが１２８ＭＢのときに、それぞれ異なるサイズ（１２ＭＢおよび１８ＭＢ）の直接マップ領域サイズが指定されていることが示されている。

なお、図６では省略しているが、第２の実施の形態では、ＮＶ−ＲＡＭ３０６ｂなどの不揮発メモリに、複数の容量情報のうち適用する容量情報のフラグを記憶する。例えば、ＮＶ−ＲＡＭ３０６ｂの予め定められたアドレスを当該フラグの設定用に用意し、後述する変更部６１６のみが変更できるように、このアドレスにフラグを記憶する。

取得部６２１ｂは、ＮＶ−ＲＡＭ３０６ｂからフラグを読込み、読み込んだフラグに対応する容量情報を参照して、物理メモリサイズに対応する直接マップ領域サイズを取得する。

変更部６１６は、ＮＶ−ＲＡＭ３０６ｂの所定のアドレスに設定された容量情報のフラグを、ユーザによって変更可能とするためのアプリケーションである。変更部６１６は、例えば、ＮＶ−ＲＡＭ３０６ｂの所定のアドレスからフラグを読み出し、オペレーションパネル３１０に変更可能に表示する。そして、変更部６１６は、オペレーションパネル３１０からユーザが指定したフラグによって、ＮＶ−ＲＡＭ３０６ｂのフラグを更新する。このように、変更部６１６は、ＮＶ−ＲＡＭ３０６ｂ上のフラグを書き換えるだけのものであり、使用する汎用領域の容量は、その他のアプリケーションと比較して充分に小さいものである。

次に、このように構成された第２の実施の形態にかかる融合機６００によるメモリ確保処理について説明する。図８は、第２の実施の形態におけるメモリ確保処理の全体の流れを示すフローチャートである。

まず、取得部６２１ｂは、ＮＶ−ＲＡＭ３０６ｂの所定のアドレスから容量情報のフラグを読込む（ステップＳ８０１）。次に、取得部６２１ｂは、読込んだフラグに対応する容量情報を保持部６２１ａから取得する（ステップＳ８０２）。

ステップＳ８０３からステップＳ８１０までの、取得判定処理、サイズ取得処理、および領域確保処理は、第１の実施の形態にかかる融合機１００におけるステップＳ５０２からステップＳ５０９までと同様の処理なので、その説明を省略する。

このように、第２の実施の形態にかかる画像処理装置では、搭載されているメモリの容量に応じた直接マップ領域の容量を、複数の容量の候補から指定することができる。これにより、融合機の使用形態等に応じて、起動時に獲得する汎用領域と直接マップ領域のサイズを切替えることができる。すなわち、使用形態等に応じてメモリの使用効率をさらに改善することが可能となる。

以上のように、本発明にかかる画像処理装置およびメモリ確保方法は、プロセスから物理メモリ内の領域を直接マップ可能なメモリ管理方法を採用した装置に適している。

第１の実施の形態にかかる融合機の機能ブロック図である。 第１の実施の形態の容量情報のデータ構造の一例を示す説明図である。 図１に示した融合機のハードウェア構成を示すブロック図である。 物理メモリと仮想メモリ領域との対応例を示す図である。 第１の実施の形態におけるメモリ確保処理の全体の流れを示すフローチャートである。 第２の実施の形態にかかる融合機の機能ブロック図である。 第２の実施の形態の容量情報のデータ構造の一例を示す説明図である。 第２の実施の形態におけるメモリ確保処理の全体の流れを示すフローチャートである。

符号の説明

１００ 融合機
１０１ Ｂ＆Ｗ ＬＰ
１０２ Ｃｏｌｏｒ ＬＰ
１０３ その他ハードウェアリソース
１０５ ハードウェア資源
１１０ ソフトウェア群
１１１ プリンタアプリ
１１２ コピーアプリ
１１３ ファックスアプリ
１１４ スキャナアプリ
１２０ プラットフォーム
１２１ａ 保持部
１２１ｂ 取得部
１２１ｃ 確保部
１３０ アプリケーション
１４０ 融合機起動部
１５０ コントロールサービス
１６０ ハンドラ層
３００ コントローラ
３０１ ＡＳＩＣ
３０２ ＭＥＭ−Ｃ
３０３ ＨＤＤ
３０４ ＣＰＵ
３０５ ＮＢ
３０６ａ ＭＥＭ−Ｐ
３０６ｂ ＮＶ−ＲＡＭ
３０７ ＳＢ
３０８ ＡＧＰ
３０９ ネットワークＩ／Ｆコントローラ
３１０ オペレーションパネル
３２０ ＦＣＵ
３３０ ＵＳＢデバイス
３４０ ＩＥＥＥ１３９４デバイス
３５０ エンジン部
１０ 物理メモリ
１１ カーネル領域
１２ 汎用領域
１３ ＭＥＭ−Ｐ０領域
１４ ＭＥＭ−Ｐ領域
１５ ＭＥＭ−Ｃ領域
２０ 仮想メモリ領域
２１ ユーザプログラム領域
２２ 直接マップ領域
２３ スタック領域
２１１ プログラムコード領域
２１２ プログラムデータ領域
２１３ ヒープ領域
２２１ ＭＥＭ−Ｐ０領域
２２２ ＭＥＭ−Ｐ領域
２２３ ＭＥＭ−Ｃ領域
６００ 融合機
６１０ ソフトウェア群
６１６ 変更部
６２１ｂ 取得部
６２１ａ 保持部
６３０ アプリケーション

Claims (6)

1. ハードウェア資源を利用した画像処理にかかるアプリケーションと、オペレーティングシステムと、前記オペレーティングシステム上で動作し、複数の前記アプリケーションからアクセスされて前記ハードウェア資源の制御を行う制御手段とを備えた画像処理装置であって、
   データを記憶する物理メモリと、
   搭載可能な前記物理メモリの容量と、前記アプリケーションおよび前記制御手段の少なくとも一方が管理する仮想メモリ領域にマッピングする前記物理メモリ内の領域である直接マップ領域の容量とを対応づけた容量情報を保持する保持手段と、
   前記保持手段に保持された前記容量情報から、搭載されている前記物理メモリの容量に対応する前記直接マップ領域の容量を取得する取得手段と、
   取得された前記容量の前記直接マップ領域を、搭載されている前記物理メモリ内に確保する確保手段と、
   を備えたことを特徴とする画像処理装置。
2. 前記保持手段は、複数の異なる前記容量情報と、前記容量情報のそれぞれを識別する識別子とを対応づけて保持し、
   複数の前記容量情報のうち、指定された前記容量情報の前記識別子を記憶する識別子記憶手段をさらに備え、
   前記取得手段は、前記識別子記憶手段に記憶されている前記識別子に対応する前記容量情報から、搭載されている前記物理メモリの容量に対応する前記直接マップ領域の容量を取得すること、
   を特徴とする請求項１に記載の画像処理装置。
3. 前記識別子記憶手段に記憶されている前記識別子を、ユーザの指定に応じて他の前記識別子に変更する変更手段をさらに備えたこと、
   を特徴とする請求項２に記載の画像処理装置。
4. 前記確保手段は、搭載されている前記物理メモリの予め定められたアドレスを先頭アドレスとして、取得した前記容量の前記直接マップ領域を、搭載されている前記物理メモリ内に確保すること、
   を特徴とする請求項１に記載の画像処理装置。
5. 前記確保手段は、前記物理メモリ内の前記直接マップ領域以外の領域に、前記オペレーティングシステムが管理する仮想メモリ領域にマッピングする前記物理メモリ内の領域である汎用領域を確保すること、
   を特徴とする請求項１に記載の画像処理装置。
6. ハードウェア資源を利用した画像処理にかかるアプリケーションと、オペレーティングシステムと、前記オペレーティングシステム上で動作し、複数の前記アプリケーションからアクセスされて前記ハードウェア資源の制御を行う制御手段とを備えた画像処理装置で行われるメモリ確保方法であって、
   前記画像処理装置は、
   データを記憶する物理メモリと、
   搭載可能な前記物理メモリの容量と、前記アプリケーションおよび前記制御手段の少なくとも一方が管理する仮想メモリ領域にマッピングする前記物理メモリ内の領域である直接マップ領域の容量とを対応づけた容量情報を保持する保持手段と、を備え、
   取得手段が、前記保持手段に保持された前記容量情報から、搭載されている前記物理メモリの容量に対応する前記直接マップ領域の容量を取得する取得ステップと、
   確保手段が、取得された前記容量の前記直接マップ領域を、搭載されている前記物理メモリ内に確保する確保ステップと、
   を備えたことを特徴とするメモリ確保方法。

Images