ラスタ化のためのメモリマネージメント方法、コンピュータ可読媒体及びコンピュータ可読メモリ
【課題】フレームバッファメモリおよびディスプレイリストメモリを備える単一のメモリプールをマネージメントする。
【解決手段】単一のメモリプールは、複数のスーパーブロックオブジェクトを有するスーパーブロックプールと、複数のノードオブジェクトを有するノードプールと、複数のブロックを有するブロックプールとを含むサブプールを備え得る。この方法は、ローカルサブプールオブジェクトがメモリ要求を満たすために利用できる場合に、メモリ要求側で識別されたサブプールにローカルなオブジェクトを割り当て、メモリ要求がノードプールまたはブロックプールへ向けられており、メモリ要求を満たすために各サブプール内に利用可能なローカルオブジェクトが存在しない場合に、スーパーブロックプールからのオブジェクトを割り当て、サブプールが利用可能な空きオブジェクトを欠く場合に、複数のメモリ解放ストラテジーのうちの少なくとも１つを適用する。
【解決手段】単一のメモリプールは、複数のスーパーブロックオブジェクトを有するスーパーブロックプールと、複数のノードオブジェクトを有するノードプールと、複数のブロックを有するブロックプールとを含むサブプールを備え得る。この方法は、ローカルサブプールオブジェクトがメモリ要求を満たすために利用できる場合に、メモリ要求側で識別されたサブプールにローカルなオブジェクトを割り当て、メモリ要求がノードプールまたはブロックプールへ向けられており、メモリ要求を満たすために各サブプール内に利用可能なローカルオブジェクトが存在しない場合に、スーパーブロックプールからのオブジェクトを割り当て、サブプールが利用可能な空きオブジェクトを欠く場合に、複数のメモリ解放ストラテジーのうちの少なくとも１つを適用する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、印刷の分野に関し、詳しくは、ラスタ化のためのメモリマネージメント方法、コンピュータ可読媒体及びコンピュータ可読メモリに関する。
【背景技術】
【０００２】
文書処理ソフトウェアによれば、ユーザは、文書を都合よく閲覧し、編集し、処理し、記憶することができる。文書中のページは、それらが印刷物に現れるとおりに、スクリーン上に正確に表示され得る。しかしながら、文書を印刷する前に、文書中のページは、多くの場合、ページ記述言語（「ＰＤＬ」）で記述される。この文書において使用されるように、ＰＤＬには、ポストスクリプト（商標）、アドビ（商標）ＰＤＦ、ＨＰ（商標）ＰＣＬ、マイクロソフト（商標）ＸＰＳ（商標）、並びにこれらの変形体、および文書中のページを記述するために使用される他の言語が含まれ得る。文書のＰＤＬ記述によれば、文書中のそれぞれのページのハイレベルな記述がもたらされる。このＰＤＬ記述は、文書が印刷されるときには、多くの場合、一連のよりローレベルなプリンタ特有コマンドへ変換される。文書のＰＤＬ記述から、印刷媒体にマークを付けるために使用することのできる、よりローレベルの記述への変換の処理は、ラスタ化と称される。
【０００３】
ＰＤＬからよりローレベルなプリンタ特有コマンドへの変換処理は、複雑になりかねず、また、特定のプリンタによってもたらされる特性および機能に左右されることがある。文書のＰＤＬ記述をプリンタ特有コマンドへ変換するための、順応性がありかつ移植可能な（portable）多目的方式によれば、利用可能なメモリ、所望の印刷速度、他のコストおよび性能基準に基づいたプリンタ性能の最適化が可能になる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来、印刷システムにおけるメモリは、ディスプレイリストメモリとフレームバッファメモリとを備える２つの別個のプールに体系化（organized）されている。ディスプレイリストメモリは、一般にラスタ化のためのディスプレイリストオブジェクトを保持し、フレームバッファメモリは、一般に、印刷されるページに形成されるべきマークを特定するビットマップデータを保持する。別個のメモリプールの使用は、フレームバッファ目的のためのディスプレイリストメモリの使用を妨げ、逆もまた同様である。印刷失敗はいずれかのプール内のメモリ不足に起因して生じる可能性がある。このような状況では、一方のプール内に十分な追加メモリが存在することがあるが、２つのプールの分離性のため、メモリは他方のメモリプールで使用するためには利用不可能である。その上、ディスプレイリストメモリプールおよびフレームバッファメモリプールをマネージメントするための別個のメモリのマネージメントルーチンの使用は、プロダクトファミリを通じてメモリをマネージメントするために使用されるコードを修正し維持するのを困難にすることがある。個別のプロダクトにおいては、異なるストラテジー（strategies）および最適化が使用され得るためである。たとえば、ディスプレイリストメモリが使い尽くされるとき、あるプロダクトは事前ラスタ化を始動させ、別のプロダクトはディスプレイリストメモリをディスクにスワップすることがある。統一性の欠如と、実施されるメモリマネージメントルーチンの多くの場合でのばらばらな組み合わせとが、最新版を提供すること、および機能性と性能を改善することの困難さを非常に増大させる。
【０００５】
よって、ラスタ化のためのプリンタ上のメモリをマネージメントする方法、コンピュータ可読媒体及びコンピュータ可読メモリであって、付加的な最適化を行いつつ、継ぎ目のないアップグレードパスを可能にするものが求められている。
【課題を解決するための手段】
【０００６】
開示された実施形態によれば、フレームバッファメモリおよびディスプレイリストメモリを備える単一のメモリプールをマネージメントする方法、コンピュータ可読媒体及びコンピュータ可読メモリが示される。いくつかの実施形態では、単一のメモリプールは、複数のスーパーブロックオブジェクトを有するスーパーブロックプールと、複数のノードオブジェクトを有するノードプールと、複数のブロックオブジェクトを有するブロックプールと、を含むサブプールを備えることができる。この方法は、サブプールのうちの少なくとも１つへ向けられたメモリ割り当て要求を受信するステップと、ローカルオブジェクトがメモリ要求を満たすためにサブプール内で利用可能である場合に、メモリ要求に応答してサブプールにローカルなオブジェクトを割り当てるステップと、メモリ要求がノードプールまたはブロックプールへ向けられており、メモリ要求を満たすためにそれぞれのサブプール内に利用可能なローカルオブジェクトが存在しない場合に、メモリ要求に応答してスーパーブロックプールからのオブジェクトを割り当てるステップと、いずれのサブプール内にも利用可能な空きオブジェクトが存在しない場合に、複数のメモリ解放ストラテジーのうちの少なくとも１つを適用するステップと、を備えることがある。
【０００７】
実施形態は、コンピュータ可読媒体またはコンピュータ可読メモリを使用してプロセッサによって作成、保存、アクセス、または、修正された方法にも関する。
【０００８】
上記の実施形態およびその他の実施形態は次の図面を参照して以下にさらに説明されている。
【図面の簡単な説明】
【０００９】
【図１】いくつかの実施形態により文書を印刷するシステムにおける構成要素を示すブロック図である。
【図２】例示的なプリンタのハイレベルブロック図である。
【図３】メモリプールのマネージメントのためのシステムの例示的なハイレベルアーキテクチャを示す図である。
【図４】メモリプール３１０のマネージメントのための例示的なクラス階層を示す図である。
【図５】ラスタ化での例示的なメモリの割り当てを説明するためのスナップショットを示す図である。
【図６】メモリプール３１０からの新しいブロックの割り当てのためのアルゴリズムの例示的なフローチャート７００である。
【図７】割り当てられたブロックへのポインタを取得するために例示的な方法で実行されるステップを説明するフローチャートである。
【図８】割り当てられるべき適切なメモリプールと、対応するオブジェクトとを決定する例示的な所定のルーチン７３０のフローチャートである。
【発明を実施するための形態】
【００１０】
本発明の種々の特徴を反映する実施形態によれば、第１の印刷可能データから生成される第２の形式すなわち中間形式の印刷可能データの自動的な保存、操作、および処理のシステムおよび方法が示される。いくつかの実施形態では、第１の印刷可能データは文書のＰＤＬ記述の形式をとることがあり、中間印刷可能データはＰＤＬ記述から生成されるオブジェクトのディスプレイリストの形式をとることがある。
【００１１】
図１は、本発明のいくつかの実施形態によって文書を印刷するためのシステムにおける構成要素を示すブロック図である。図１に示すように、本発明と整合性を有するコンピュータソフトウェアアプリケーションはコンピュータのネットワークで展開することができ、このネットワークは、従来の通信プロトコルおよび／またはデータポートインターフェースを使って情報が交換されることを可能にする通信リンクを介して接続されている。
【００１２】
図１に示すように、例示的なシステム１００には、演算装置１１０とサーバ１３０とを含む複数のコンピュータが備えられる。さらに演算装置１１０とサーバ１３０とはコネクション１２０を通して交信し、コネクションはネットワーク１４０を通る。ネットワーク１４０は、一例ではインターネットとすることもできる。演算装置１１０はコンピュータワークステーション、デスクトップコンピュータ、ラップトップコンピュータ、またはネットワーク環境で使用することのできる他の演算装置とすることができる。サーバ１３０は、演算装置１１０およびその他の装置（図示しない）へ接続することのできるプラットフォームとすることができる。演算装置１１０とサーバ１３０とは、プリンタ１７０を使った文書の印刷を可能にするソフトウェア（図示しない）を実行することができる。
【００１３】
例示的なプリンタ１７０は電子データから物理文書を生成する装置を含んでおり、この装置にはレーザープリンタ、インクジェットプリンタ、ＬＥＤプリンタ、プロッタ、ファクシミリ装置、およびディジタルコピー機が包含されるが、これらに限定されない。いくつかの実施形態では、プリンタ１７０は、演算装置１１０またはサーバ１３０からコネクション１２０を介して受信した文書を直接印刷することもできる。いくつかの実施形態においては、このような構成は、演算装置１１０またはサーバ１３０による追加の処理を伴って（またはこれを伴わずに）、文書の直接印刷を可能にする。いくつかの実施形態においては、文書はテキスト、図形、および画像のうちの１つ以上を含む。いくつかの実施形態においては、プリンタ１７０は印刷用の文書のＰＤＬ記述を受信することができる。また、文書印刷処理を分散させることもできることに留意されたい。よって、演算装置１１０、サーバ１３０、および／またはプリンタ１７０は、文書がプリンタ１７０によって物理的に印刷される前に、ハーフトーニング、カラーマッチング、および／またはその他の操作プロセスといった文書印刷処理の部分を実行し得る。
【００１４】
また演算装置１１０は着脱可能型メディアドライブ１５０も含む。着脱可能型メディアドライブ１５０には、例えば、３．５インチフロッピードライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＯＭドライブ、ＣＤ±ＲＷもしくはＤＶＤ±ＲＷドライブ、ＵＳＢフラッシュドライブ、および／または本発明の実施形態と整合性を有する他の着脱可能型メディアドライブなどが含まれ得る。いくつかの実施形態においては、ソフトウェア・アプリケーションの一部は、着脱可能型メディアに存在していてもよく、また、着脱可能型メディアドライブ１５０を使用して演算装置１１０によって読み取られ、実行される。
【００１５】
コネクション１２０は、演算装置１１０とサーバ１３０とプリンタ１７０とを接続するものであり、従来の通信プロトコルおよび／またはデータポートインターフェースを使った有線または無線の接続として実施され得る。一般にコネクション１２０は、装置間のデータの伝送を可能にする任意の通信路とすることができる。一実施形態では、例えば各装置は、パラレルポート、シリアルポート、イーサネット（商標）、ＵＳＢ、ＳＣＳＩ、ＦＩＲＥＷＩＲＥ（商標）、および／または適切な接続を介したデータ伝送用の同軸ケーブルポートといった、従来のデータポートを備える。いくつかの実施形態においては、コネクション１２０は、ディジタル加入者線（ＤＳＬ）、非対称ディジタル加入者線（ＡＤＳＬ）、またはケーブル接続とすることができる。通信リンクは無線リンクでも、有線リンクでも、様々な装置間の通信を可能とする本発明の各実施形態と整合性を有する任意の組み合わせとすることもできる。
【００１６】
ネットワーク１４０はローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、またはインターネットを含んでいてもよい。いくつかの実施形態においては、ネットワーク１４０を介して送られる情報は、送信されるデータのセキュリティを確保するために暗号化することができる。プリンタ１７０はコネクション１２０を介してネットワーク１４０へ接続することができる。いくつかの実施形態においては、プリンタ１７０は演算装置１１０および／またはサーバ１３０へ直接接続される。またシステム１００は、本発明のいくつかの実施形態によれば、他の周辺機器（図示しない）を含んでいてもよい。本発明と整合性を有するコンピュータソフトウェアアプリケーションは、図１に示すように、例示的コンピュータおよびプリンタのいずれに配備されていてもよい。例えば、演算装置１１０は、サーバ１３０から直接ダウンロードされるソフトウェアを実行することもできる。これらのアプリケーションの各部分は、本発明のいくつかの実施形態に従って、プリンタ１７０によって実行されても良い。
【００１７】
図２に例示的なプリンタ１７０のハイレベルなブロック図を示す。いくつかの実施形態においては、プリンタ１７０は、ＣＰＵ１７６、ファームウェア１７１、メモリ１７２、入出力ポート１７５、印刷エンジン１７７、および補助記憶装置１７３を接続するバス１７４を含む。またプリンタ１７０は、本発明のいくつかの実施形態によれば、ＰＰＭＬを処理するためのアプリケーションの一部分を実行することのできるその他の特定用途向け集積回路（ＡＳＩＣ）、および／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）１７８を含んでいてもよい。いくつかの実施形態では、プリンタ１７０は、入出力ポート１７５およびコネクション１２０を使って２次記憶メモリまたは演算装置１１０内のその他のメモリにアクセスすることもできる。いくつかの実施形態では、プリンタ１７０は、プリンタオペレーティングシステムおよび他の適切なアプリケーションソフトウェアを含むソフトウェアを実行することもできる。いくつかの実施形態においては、プリンタ１７０は、他のオプションのうち、用紙サイズ、排紙トレイ、色選択、および印刷解像度をユーザ設定可能なものにすることができる。
【００１８】
いくつかの実施形態では、ＣＰＵ１７６は、汎用プロセッサとすることも、専用プロセッサとすることも、組み込みプロセッサとすることもできる。ＣＰＵ１７６は、制御情報および命令を含むデータをメモリ１７２および／またはファームウェア１７１と交換することができる。メモリ１７２は、ＳＤＲＡＭやＲＤＲＡＭといった任意の種類のダイナミックランダムアクセスメモリ（ＤＲＡＭ）とすることができるが、これらには限定されない。ファームウェア１７１は、起動シーケンス、事前定義のルーチン、およびその他のコードを含む命令およびデータを保持するが、これらには限定されない。いくつかの実施形態では、ファームウェア１７１の中のコードおよびデータは、ＣＰＵ１７６によって処理される前にメモリ１７２へコピーされる。ファームウェア１７１に含まれるルーチンには、演算装置１１０から受け取られるページ記述をディスプレイリストおよび画像バンドへ変換するためのコードを含めることができる。いくつかの実施形態においては、ファームウェア１７１には、ディスプレイリストにおける表示コマンドを適切なラスタ化ビットマップへ変換するとともに当該ビットマップをメモリ１７２の中に記憶するためのラスタ化ルーチンが含まれても良い。また、ファームウェア１７１には、圧縮ルーチンおよびメモリマネージメントルーチンが含まれていてもよい。いくつかの実施形態においては、ファームウェア１７１内のデータおよび命令をアップグレード可能とすることもできる。
【００１９】
いくつかの実施形態においては、ＣＰＵ１７６が命令およびデータに従って動作し、ＡＳＩＣＳ／ＦＰＧＡＳ１７８および印刷エンジン１７７に制御およびデータを提供して印刷文書を生成する。いくつかの実施形態においては、ＡＳＩＣＳ／ＦＰＧＡＳ１７８が印刷エンジン１７７に制御およびデータを提供する。またＦＰＧＡＳ／ＡＳＩＣＳ１７８は、変換、圧縮、およびラスタ化のアルゴリズムのうちの１つ以上を実施してもよい。いくつかの実施形態においては、演算装置１１０が文書データを第１の印刷可能データに変換することができる。次いで第１の印刷可能データを、中間印刷可能データに変換するためにプリンタ１７０に送ることができる。プリンタ１７０は、中間印刷可能データを最終形態の印刷可能データに変換して、この最終形態に従って印刷を行う。いくつかの実施形態においては、第１の印刷可能データは、文書のＰＤＬ記述に該当する。いくつかの実施形態では、文書のＰＤＬ記述から、一連のよりローレベルなプリンタ特有コマンドを有する上記最終形態の印刷可能データへの変換処理には、オブジェクトのディスプレイリストを有する中間印刷可能データの生成が含まれている。
【００２０】
いくつかの実施形態では、ディスプレイリストには、テキスト、図形、および画像のデータオブジェクトの１つ以上が保有されていてもよい。いくつかの実施形態では、ディスプレイリストの中のオブジェクトは、ユーザ文書の中の類似オブジェクトに対応していてもよい。いくつかの実施形態では、ディスプレイリストは、中間印刷可能データの生成を支援することができる。いくつかの実施形態では、ディスプレイリストは、メモリ１７２あるいは補助記憶装置１７３の中に記憶することができる。例示的な補助記憶装置１７３は、内部あるいは外部のハードディスク、メモリスティック、あるいはシステム２００に使用することのできる他の記憶装置であってよい。いくつかの実施形態では、上記ディスプレイリストは、プリンタ１７０、演算装置１１０、およびサーバ１３０の１つ以上に存在していてもよい。ディスプレイリストを記憶するためのメモリは、開示された実施形態によれば、専用メモリであってもよく、または、汎用メモリの一部を形成してもよく、または、専用メモリと汎用メモリのある種の組み合わせでもよい。いくつかの実施形態では、メモリは、複数のディスプレイリストを必要に応じて保有するために動的（dynamically）に割り当てることができるようになっている。いくつかの実施形態では、複数のディスプレイリストを記憶するために割り当てられたメモリは、処理の後に動的に解放（released）されるようになっている。
【００２１】
図３はメモリプールのマネージメントのためのシステムの例示的なハイレベルアーキテクチャを示している。図３に示されているように、言語サーバ３４０、エンジンサーバ３６０、およびラスタサーバ３２０は、互いに通信することができる。加えて、言語サーバ３４０、エンジンサーバ３６０、およびラスタサーバ３２０は、ルーチンを呼び出すとともにＲＤＬライブラリ３３０と通信することができる。このシステムは、ラスタサーバ３２０、エンジンサーバ３６０、およびメモリマネージメントアプリケーションプログラミングインターフェイス（ＡＰＩ）３７０と通信するフレームバッファマネージメントライブラリ３３５をさらに含んでもよい。いくつかの実施形態では、メモリマネージャ３７５によって提供される機能性（functionality）の使用は、メモリマネージメントアプリケーションプログラミングインターフェイス（ＡＰＩ）３７０を介して行われてもよい。メモリマネージャ３７５はメモリマネージメントＡＰＩ３７０の機能（functions）を定義する。いくつかの実施形態では、フレームバッファライブラリ３３５内のコードのように、ディスプレイリストおよびフレームバッファ３５０に関係があるコードは、メモリマネージメントＡＰＩ３７０を介してメモリマネージャ３７５と接続する（intreface）。したがって、これらの実施形態では、メモリマネージャは、ディスプレイリストまたはフレームバッファをマネージメントおよび／または操作するために使用されるプログラムコードを変更することなく、プロダクト固有のメモリマネージャによって置き換えられるか、または修正され得る。いくつかの実施形態では、ディスプレイリストは、印刷されるべき文書内、または印刷されるべき文書におけるページ内でのデータオブジェクトと、これらデータオブジェクトのコンテキストとを定義するコマンドを含んでもよい。これらの表示コマンドには、文字あるいはテキスト、ラインドローイングあるいはベクトル、及び、画像あるいははラスタデータを有するデータが含まれていてもよい。
【００２２】
いくつかの実施形態では、ディスプレイリストは、動的に再構成することのできるものであり、また、再構成可能型ディスプレイリスト（ＲＤＬ）と呼ばれる。１つの実施形態では、或るディスプレイリストオブジェクトが動的に操作できる態様で記憶されるデータ構造を使用して、ＲＤＬを実施することができる。例えば、画像オブジェクトは、利用可能なメモリの量を増大させるために適切に圧縮されてもよく、また、参照されかつ／または使用されるときに復元されてもよい。いくつかの実施形態では、ＲＤＬはまた、ＲＤＬオブジェクトの実際の記憶場所へのポインタ、オフセット値（offsets）、あるいはアドレスを保持することでＲＤＬオブジェクトをメモリおよび／または補助記憶装置に記憶させることができ、その後、ＲＤＬオブジェクトが参照されかつ／または使用されるときにこの実際の記憶場所が検索される。一般に、ＲＤＬによれば、ディスプレイリストオブジェクトは、順応性を伴って記憶することができるとともに、システムの制約条件およびパラメータに基づいて操作することができる。
【００２３】
１つの実施形態では、文書のＰＤＬ記述をディスプレイリストおよび／またはＲＤＬ表示へ変換することは、ＲＤＬライブラリ３３０およびメモリマネージャ３７５の中のルーチンを用いて言語サーバ３４０によって実行することができる。例えば、言語サーバ３４０は、ＰＤＬ言語基本要素を受け取り、かつ、これらのＰＤＬ言語基本要素をデータおよび図形オブジェクトに変換し、さらに、ＲＤＬライブラリ３３０およびメモリマネージャ３７５の中の関数によってもたらされる機能を用いて、再構成可能なディスプレイリストへこれらデータおよび図形オブジェクトを追加することができる。いくつかの実施形態では、メモリマネージャ３７５の中の関数およびルーチンへのアクセスは、メモリマネージメントＡＰＩ３７０を通してもたらされる。いくつかの実施形態では、ディスプレイリストは、例示的なメモリプール３２０のような、動的に割り当てられたメモリプールの中において、記憶され、操作される。このメモリプールは、メモリ１７２の一部であってもよい。
【００２４】
いくつかの実施形態では、ＲＤＬを作成することは、実際の印刷に先立つデータの処理における中間ステップであってもよい。ＲＤＬは、変換される前に、その後の形態（a subsequent form）に構文解析される。いくつかの実施形態では、その後の形態は最終表示であってもよく、また、変換処理はデータのラスタ化と呼ばれることがある。いくつかの実施形態では、フレームバッファマネージメントライブラリ３３５内のルーチンを使用してラスタ化はラスタサーバ３２０によって実行されてもよい。ラスタ化の際に、ラスタ化されたデータは、メモリマネージメントＡＰＩ３７０を介してアクセスされるメモリマネージャ３７５内のルーチンを使用して、メモリプール３１０の一部分であるフレームバッファ３５０内に保存されてもよい。いくつかの実施形態では、ラスタ化されたデータは、印刷ページに付けられるマークを指定するビットマップの形態を採ることができる。
【００２５】
一実施形態では、メモリマネージャ３７５内のルーチンは、メモリ１７２内における利用可能なメモリのいくつかのサブセットをメモリプール３１０として管理し、メモリマネージメントＡＰＩ３７０を介して、要求されている処理にメモリプール３１０中からメモリを割り当ててもよい。いくつかの実施形態では、メモリマネージャ３７５は、メモリマネージメントＡＰＩ３７０と相互作用し、メモリマネージャ３７５によって提供される機能へのアクセスがメモリマネージメントＡＰＩ３７０を介して行われる。要求されている処理によってメモリがもはや必要とされないときには、メモリは、割り当て解除されてメモリプール１３０へ戻り、他の処理に利用可能なものとなることができる。いくつかの実施形態では、メモリマネージャ３７０内のルーチンには、メモリ解放へのルーチン（routines to free memory）、メモリ回復へのルーチン（routines to recover memory）、およびメモリを補助記憶装置１７３へスワップすることのできるスワッピングルーチンが包含される他のさまざまなメモリマネージメントルーチンもまた含まれている。いくつかの実施形態では、フレームバッファ３５０はメモリプール３１０の一部分でもよく、メモリマネージャ３７０によって管理されてもよい。たとえば、フレームバッファマネージメントライブラリ３３５内の関数への呼び出しは、メモリマネージメントＡＰＩ３７０内の関数への呼び出しをもたらすことがある。その後に、メモリマネージメントＡＰＩは、メモリマネージャ３７０内の１つ以上の関数を呼び出すことがある。メモリマネージャ３７５によって行われた動作の結果は、呼び出し側プロセスへ送られる（be routed back to）ことがある。一実施形態では、フレームバッファ３５０は、メモリの一次連続ブロック（an initial contiguous block）へ割り当てられてもよく、また、その後のメモリブロックは、要求されたときにフレームバッファ３５０へ割り当てられてもよい。メモリブロックは、他のフレームバッファ目的のためにメモリプール３１０から割り当てられてもよい。いくつかの実施形態では、フレームバッファ３５０またはその他の処理に割り当てられた異なるメモリブロックによって、メモリ１７２内の非連続な記憶場所が占領される。
【００２６】
印刷エンジン１７７は、フレームバッファライブラリ３３５内のルーチンを使用して、ラスタ化されたデータをフレームバッファ３５０の中で処理し、用紙のような印刷媒体の上にページの印刷可能画像を形成することができる。いくつかの実施形態では、ラスタサーバ３２０およびエンジンサーバ３６０はまた、これらの機能を実行するために、ＲＤＬライブラリ３３０の中のルーチンを使用することができる。いくつかの実施形態では、エンジンサーバ３６０は、印刷エンジン１７７へ制御情報、指示、およびデータを提供することができる。いくつかの実施形態では、エンジンサーバ３６０は、メモリプール３２０へ返却するための処理後に、フレームバッファライブラリ及びメモリマネージメントＡＰＩ３７０を介してメモリマネージャ３７５によって提供される機能を使用して、ディスプレイリストオブジェクトによって使用されたメモリを解放させるルーチンを呼び出すことがある。いくつかの実施形態では、ＲＤＬメモリプールの一部および／またはフレームバッファ３５０は、メモリ１７２あるいは補助記憶装置１７３の中に存在していてもよい。いくつかの実施形態では、言語サーバ３４０、ラスタサーバ３２０、およびエンジンサーバ３６０のためのルーチンはファームウェア１７１の中に設けられてもよく、あるいは、ＡＳＩＣＳ／ＦＰＧＡＳ１７８を使用して実施されてもよい。
【００２７】
図４は、ラスタ化中にメモリプールをマネージメントするシステムの例示的なオブジェクト指向型実施における例示的なクラス図５００の一部を示している。このクラス構造は、永続的な（persistent）単体のｍｍ主制御装置５１０を含む。ｍｍ主制御装置５１０を永続的な単体として宣言することによって、ｍｍ主制御装置５１０の単一インスタンスがあるということと、ｍｍ主制御装置５１０の同一性がコード実行中に変化しないということと、ｍｍ主制御装置５１０へのアクセスの大域包括的な箇所（a global point of access to Master Control）があるということが保証される。クラス、サブクラス、および／またはオブジェクト５２０〜５６０によって、ラスタ化中のメモリマネージメントのためのシステムの一つの実施が示されている。さまざまなクラスに属しているオブジェクトは、実行中にインスタンス化することができる。
【００２８】
図４に示されているように、ｍｍ主制御装置５１０は、クラスｍｍプール５６０の３つのオブジェクトを含む。これらのオブジェクトは、ノードオブジェクト、ブロックオブジェクト、およびスーパーブロックオブジェクトを有する。これらのｍｍプールオブジェクトは、共有されたメモリプール３１０のマネージメントにおいて使用され得る。たとえば、メモリプール３１０は、スーパーブロックプール５６０−１、ノードプール５６０−２、およびブロックプール５６０−３を有すると論理的にみなされ得る。したがって、スーパーブロックプール５６０−１、ノードプール５６０−２、およびブロックプール５６０−３は、メモリプール３１０のサブプールである。さらに、各サブプールは当該サブプールにローカルな（local to that sub-pool）オブジェクトを有する可能性がある。オブジェクトと共に「ローカル」という用語を使用することは、記述的な目的のためにオブジェクトとそれぞれのプールとを関連付けるだけのために役立つ。したがって、スーパーブロックオブジェクトはスーパーブロックプール５６０−１にローカルでもよく、ノードオブジェクトはノードプール５６０−２にローカルでもよく、ブロックオブジェクトはブロックプール５６０−３にローカルでもよい。たとえば、フレームバッファ３５０と関連付けられたフレームバッファマネージメントライブラリ３３５内のルーチンは、メモリマネージメントＡＰＩ３７０を介してメモリマネージャ３７５を使用し、スーパープール５６０−１にスーパーブロックを要求することが可能である。同様に、ＲＤＬによってブロックオブジェクトがブロックプール５６０−３に要求されることがある。ｍｍノードオブジェクト５３０は、ブロック割り当ておよびスーパーブロック割り当てをマネージメントする要求時に、ノードプール５６０−２からメモリマネージャ５７５によって割り当てられ得る。一実施形態では、１つのｍｍノードオブジェクト５３０は、ブロックの割り当て毎、或いはスーパーブロックの割り当て毎に使用されてもよい。いくつかの実施形態では、１つずつの個別のオブジェクトは、メモリの離散的な連続セクションを含んでもよい。
【００２９】
いくつかの実施形態では、ｍｍ主制御装置５１０は、ｍｍ優先度つきキューオブジェクト（PriorityQueue object）５５０を含むことができる。図４に示されているように、ｍｍ優先度つきキューオブジェクト５５０はｍｍリストオブジェクト５４０を含むことができる。さらに、ｍｍリストオブジェクト５４０は、ｍｍリンクオブジェクト５２０を使用してｍｍノードオブジェクト５３０を保持する。いくつかの実施では、ｍｍノードオブジェクト５３０は、割り当て済みのブロックまたはスーパーブロックのそれぞれの経過を追う（keeps track）。ｍｍ優先度つきキューオブジェクト５５０はスワップ可能なブロックの経過を追うために使用され得る。利用可能なメモリが少なく、スワッピングが使用可能であるとき、ｍｍ優先度つきキューオブジェクト５５０は、メモリからブロックをスワップする順序を決定するために使用され得る。たとえば、割り当て済みブロックは優先度と関連付けられ得る。たとえば、優先度は、ブロックをアクセスしやすい状態に保つことで得られる性能優位性の指標である場合がある。一実施形態では、ｍｍ優先度つきキューオブジェクト５５０は、優先度の増加する順序にオブジェクトを順序付け、これによって、低優先度ブロックが高優先度ブロックよりも先にスワップアウトされることを可能にすることがある。その他の関数およびルーチンは、１つ以上の高優先度のメモリチャンクを瞬時にアクセスできる形式に保つために優先番号を使用することがある。
【００３０】
図５は、ラスタ化でのメモリプール３１０の例示的な割り当てを説明するためのスナップショット６００を示している。ラスタ化中の様々な時点で、メモリプール３１０は、空きスーパーブロック６３０、割り当て済みスーパーブロック６３０−２、空きブロック６１０−１および割り当て済みブロック６１０−２にのいくつかの組み合わせを含むことがある。論理的な観点から、メモリプール３１０は、最初は空きスーパーブロック６３０−１、ノードブロック、および空きブロック６１０−１の集まりであると考えてもよい。いくつかの実施形態では、全てのスーパーブロックオブジェクトは、一様な一定サイズでもよい。いくつかの実施形態では、ブロックオブジェクトもまた一様な一定サイズでもよい。いくつかの実施形態では、ブロックオブジェクトの一様な一定サイズは、スーパーブロックオブジェクトのサイズより小さく、スーパーブロックオブジェクトのサイズと異なる。いくつかの実施形態では、スーパーブロックオブジェクトのサイズはブロックオブジェクトのサイズの整数倍でもよい。いくつかの実施形態では、スーパーブロックオブジェクトのサイズはブロックオブジェクトのサイズの偶数倍でもよい。たとえば、図５に示されているように、スーパーブロック６３０のサイズは４つのブロック６１０のサイズと等しくてもよい。
【００３１】
例えばビットマップを保存するためなど、フレームバッファ３５０による使用のためにメモリが要求されるときには、スーパーブロック６３０−１が割り当てられ得る。ＲＤＬのため、または一時的な保存および処理の目的のためにメモリが要求されるときには、より小さい単位のメモリが割り当てられ得る。たとえば、空きスーパーブロック６３０−１は等しいサイズのブロック６１０に分割されることができ、これらのブロック６１０の１つがＲＤＬのため、または、一時的な保存および処理の目的のために使用されるときに割り当てられ得る。スーパーブロックプール５６０−１、ノードプール５６０−２、およびブロックプール５６０−３の使用は、一つには、メモリ割り当ての細かさ（granularity）を制御することを可能にする。ノードプール５６０−１およびブロックブール５６０−３は、スーパーブロックプール５６０−１からのメモリを割り当てるときに増大することができる。いくつかの実施形態では、メモリプール３１０内でばらばらに散在するブロックから新しいスーパーブロックを作成するために、メモリデフラグルーチンは、周期的に、または、利用可能なメモリがある種の閾値より少ないときに用いられ、或いは、メモリを解放するストラテジーとして用いられることがある。
【００３２】
図６は、メモリプール３１０から新しいブロック６１０−１を割り当てるアルゴリズムの例示的なフローチャート７００を示している。ステップ７１０において、アルゴリズムが呼び出される。次に、所定のルーチン７３０において、新しいノードオブジェクトがノードプール５６０−２から割り当てられる。いくつかの実施形態では、新しいオブジェクトのためのメモリの割り当ては、新しい要素を割り当てる一般的な（generic）所定のルーチンを使用して実行されることがある。所定のルーチン７３０は、適切なメモリプール５６０と、割り当てられるべき対応オブジェクトとを決定するために、供給されるパラメータを使用することがある。たとえば、所定のルーチン７３０は、ノードプール５６０−２から新しいノードを割り当ててもよい。ステップ７４０において割り当てが成功であると判定される場合には、異なるパラメータのセットと共に所定のルーチン７３０を使用して、新しいスーパーブロック６３０−１又はブロック６１０−１が割り当てられてもよい。たとえば、メモリがビットマップを保存するためにフレームバッファ３５０によって使用中である場合には、所定のルーチン７３０はスーパーブロックプール５６０−３から新しいスーパーブロック６３０−１を割り当てることがある。ステップ７６０において割り当てが成功であると判定される場合には、新たに割り当てられるブロック６１０−２がノードに割り当てられ、当該ノードはステップ７７０において優先度つきキューに収容されることがある。いくつかの実施形態では、ノードはｍｍ優先度つきキューオブジェクト５５０にリンクされてもよい。所定のルーチン７３０を使用した割り当てが失敗である場合には、アルゴリズムはステップ７８０へ進み、「割り当て失敗」メッセージが呼び出し側ルーチンへ返送されてもよい。
【００３３】
図７は、割り当て済みブロック６１０−２へのポインタを取得するための例示的な方法で実行されるステップを示すフローチャート８００である。ステップ８１０において、アルゴリズムが呼び出される。次に、ステップ８２０において、割り当て済みブロック６１０−２に対応するノードが決定され得る。ステップ８３０および８４０においてそれぞれ判定されるように、ブロック６１０−２がメモリ内に存在し、ブロック６１０−２に対応するノードの参照カウントが「０」である場合には、ステップ８５０において、ノードが優先度つきキューから削除されることがある。いくつかの実施形態では、ノードを削除するために適切な動作がｍｍ優先度つきキューオブジェクト５５０で実行されることがある。
【００３４】
ステップ８３０において判定され得るように、ブロック６１０−２がメモリ内に存在しない場合には、所定のルーチン７３０は供給されるパラメータを使用し、適切なメモリプール５６０と、割り当てられるべき、対応するスーパーブロック又はブロックオブジェクトとを決定することができる。次に、ステップ８８０において判定され得るように、オブジェクトの割り当てが成功の場合には、ブロック６１０−２のためのデータが補助記憶装置１７３から読み出されるか、またはスワップインされ、アルゴリズムはステップ８６０へ進む。ステップ８４０において、ノードの参照カウントが零でない場合には、アルゴリズムはステップ８６０へ進むことができる。ステップ８６０において、ノードの参照カウントが１つ増加され、ブロック６１０−２へのポインタが返却されることがある。ステップ８８０において所定のルーチン７３０によるメモリの割り当てが失敗であると判定される場合には、ステップ８９５において「メモリ不足」メッセージが呼び出し側ルーチンへ返送される。
【００３５】
図８は、適切なメモリプールと、割り当てられるべき対応オブジェクトとを決定する例示的な所定のルーチン７３０のフローチャートを示している。ステップ９１０において、アルゴリズムが呼び出される。次に、ステップ９２０において、使用されるべきサブプールが決定される。いくつかの実施形態では、サブプールは、スーパーブロックプール５６０−１でもよく、または、ノードプール５６０−２とブロックプール５６０−３との一方でもよい。割り当て要求がスーパーブロックプール５６０−１に対して行われると、ステップ９３０において、スーパーブロックプール５６０−１内のスーパーブロック６３０−１の可用性が決定され得る。スーパーブロック６３０−１が利用可能である場合には、ステップ９４０においてスーパーブロック６３０−１が割り当てられ得る。たとえば、スーパーブロック６３０−１は、フレームバッファ３５０と関連付けられたルーチンに割り当てられることがある。
【００３６】
ノードプール５６０−２またはブロックプール５６０−３に対してブロック６１０−１の要求が行われる場合には、ステップ９６５において、ノードプール５６０−２またはブロックプール５６０−３における空き、もしくは割り当てられていない要素又は割り当てユニットについての可用性が決定され得る。ノードオブジェクトまたはブロック６１０−１が利用可能である場合には、ステップ９７０において、要求されるオブジェクトのタイプに基づいてノードオブジェクトまたはブロック６１０−１が割り当てられ得る。たとえば、ノードオブジェクトがメモリマネージャ３７５による内部使用のために割り当てられてもよい。ステップ９６５における可用性のチェックによってノードプール５６０−２またはブロックプール５６０−３内に空き要素または割り当てられていない要素が存在しないと判定される場合には、アルゴリズムはステップ９３０へ進む。ステップ９３０において、スーパーブロックプール５６０−１内のスーパーブロック６３０−１の可用性が判定され得る。スーパーブロック６３０−１が利用可能である場合には、ステップ９４０においてスーパーブロックはブロック６１０−１に分割され、適切なプール５６０−２または５６０−３に割り当てられ得る。たとえば、スーパーブロック６３０−１はブロック６１０−１に分割され、１つのブロック６１０−１がＲＤＬに割り当てられてもよい。
【００３７】
スーパーブロックプール５６０−１内に利用可能なスーパーブロック６３０−１が存在しない場合には、ステップ９６０において、アルゴリズムは、複数のメモリ解放ストラテジーのうちの一つを呼び出すことができる。たとえば、このアルゴリズムは、メモリが別のプロセスによって解放されるまで待機することができる。いくつかの実施形態では、アルゴリズムは、低優先度のノードを優先度つきキューから補助記憶装置１７３にスワップすることがある。メモリ解放ストラテジーが失敗の場合には、アルゴリズムは、メモリ不足を呼び出し側プロセスに報告することがある。
【００３８】
本発明の他の実施形態は、本明細書の考察、及び、本明細書中に開示された本発明の１つ以上の実施形態の実施により、当業者にとって明らかになるであろう。明細書及び例は例示的なものに過ぎないことを意図しており、本発明の本来の範囲及び要旨は、以下の特許請求の範囲に示されるものである。
【符号の説明】
【００３９】
１００ システム
１１０ 演算装置
１２０ コネクション
１３０ サーバ
１４０ ネットワーク
１５０ 着脱可能型メディアドライブ
１７０ プリンタ
１７１ ファームウェア
１７２ メモリ
１７３ 補助記憶装置
１７４ バス
１７５ 入出力ポート
１７６ ＣＰＵ
１７７ 印刷エンジン
１７８ ＦＰＧＡ
３１０ メモリプール
３２０ ラスタサーバ
３３０ ＲＤＬライブラリ
３３５ フレームバッファマネージメントライブラリ
３４０ 言語サーバ
３５０ フレームバッファ
３６０ エンジンサーバ
３７０ メモリマネージメントアプリケーションプログラミングインターフェイス
３７５ メモリマネージャ
５１０，５２０，５３０，５４０，５５０，５６０ オブジェクト
５６０−１ スーパーブロックプール
５６０−２ ノードプール
５６０−３ ブロックプール
６００ メモリレイアウト
６１０−１ 空きブロック
６１０−２ 割り当て済みブロック
６３０−１ 空きスーパーブロック
６３０−２ 割り当て済みスーパーブロック
【技術分野】
【０００１】
本発明は、印刷の分野に関し、詳しくは、ラスタ化のためのメモリマネージメント方法、コンピュータ可読媒体及びコンピュータ可読メモリに関する。
【背景技術】
【０００２】
文書処理ソフトウェアによれば、ユーザは、文書を都合よく閲覧し、編集し、処理し、記憶することができる。文書中のページは、それらが印刷物に現れるとおりに、スクリーン上に正確に表示され得る。しかしながら、文書を印刷する前に、文書中のページは、多くの場合、ページ記述言語（「ＰＤＬ」）で記述される。この文書において使用されるように、ＰＤＬには、ポストスクリプト（商標）、アドビ（商標）ＰＤＦ、ＨＰ（商標）ＰＣＬ、マイクロソフト（商標）ＸＰＳ（商標）、並びにこれらの変形体、および文書中のページを記述するために使用される他の言語が含まれ得る。文書のＰＤＬ記述によれば、文書中のそれぞれのページのハイレベルな記述がもたらされる。このＰＤＬ記述は、文書が印刷されるときには、多くの場合、一連のよりローレベルなプリンタ特有コマンドへ変換される。文書のＰＤＬ記述から、印刷媒体にマークを付けるために使用することのできる、よりローレベルの記述への変換の処理は、ラスタ化と称される。
【０００３】
ＰＤＬからよりローレベルなプリンタ特有コマンドへの変換処理は、複雑になりかねず、また、特定のプリンタによってもたらされる特性および機能に左右されることがある。文書のＰＤＬ記述をプリンタ特有コマンドへ変換するための、順応性がありかつ移植可能な（portable）多目的方式によれば、利用可能なメモリ、所望の印刷速度、他のコストおよび性能基準に基づいたプリンタ性能の最適化が可能になる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来、印刷システムにおけるメモリは、ディスプレイリストメモリとフレームバッファメモリとを備える２つの別個のプールに体系化（organized）されている。ディスプレイリストメモリは、一般にラスタ化のためのディスプレイリストオブジェクトを保持し、フレームバッファメモリは、一般に、印刷されるページに形成されるべきマークを特定するビットマップデータを保持する。別個のメモリプールの使用は、フレームバッファ目的のためのディスプレイリストメモリの使用を妨げ、逆もまた同様である。印刷失敗はいずれかのプール内のメモリ不足に起因して生じる可能性がある。このような状況では、一方のプール内に十分な追加メモリが存在することがあるが、２つのプールの分離性のため、メモリは他方のメモリプールで使用するためには利用不可能である。その上、ディスプレイリストメモリプールおよびフレームバッファメモリプールをマネージメントするための別個のメモリのマネージメントルーチンの使用は、プロダクトファミリを通じてメモリをマネージメントするために使用されるコードを修正し維持するのを困難にすることがある。個別のプロダクトにおいては、異なるストラテジー（strategies）および最適化が使用され得るためである。たとえば、ディスプレイリストメモリが使い尽くされるとき、あるプロダクトは事前ラスタ化を始動させ、別のプロダクトはディスプレイリストメモリをディスクにスワップすることがある。統一性の欠如と、実施されるメモリマネージメントルーチンの多くの場合でのばらばらな組み合わせとが、最新版を提供すること、および機能性と性能を改善することの困難さを非常に増大させる。
【０００５】
よって、ラスタ化のためのプリンタ上のメモリをマネージメントする方法、コンピュータ可読媒体及びコンピュータ可読メモリであって、付加的な最適化を行いつつ、継ぎ目のないアップグレードパスを可能にするものが求められている。
【課題を解決するための手段】
【０００６】
開示された実施形態によれば、フレームバッファメモリおよびディスプレイリストメモリを備える単一のメモリプールをマネージメントする方法、コンピュータ可読媒体及びコンピュータ可読メモリが示される。いくつかの実施形態では、単一のメモリプールは、複数のスーパーブロックオブジェクトを有するスーパーブロックプールと、複数のノードオブジェクトを有するノードプールと、複数のブロックオブジェクトを有するブロックプールと、を含むサブプールを備えることができる。この方法は、サブプールのうちの少なくとも１つへ向けられたメモリ割り当て要求を受信するステップと、ローカルオブジェクトがメモリ要求を満たすためにサブプール内で利用可能である場合に、メモリ要求に応答してサブプールにローカルなオブジェクトを割り当てるステップと、メモリ要求がノードプールまたはブロックプールへ向けられており、メモリ要求を満たすためにそれぞれのサブプール内に利用可能なローカルオブジェクトが存在しない場合に、メモリ要求に応答してスーパーブロックプールからのオブジェクトを割り当てるステップと、いずれのサブプール内にも利用可能な空きオブジェクトが存在しない場合に、複数のメモリ解放ストラテジーのうちの少なくとも１つを適用するステップと、を備えることがある。
【０００７】
実施形態は、コンピュータ可読媒体またはコンピュータ可読メモリを使用してプロセッサによって作成、保存、アクセス、または、修正された方法にも関する。
【０００８】
上記の実施形態およびその他の実施形態は次の図面を参照して以下にさらに説明されている。
【図面の簡単な説明】
【０００９】
【図１】いくつかの実施形態により文書を印刷するシステムにおける構成要素を示すブロック図である。
【図２】例示的なプリンタのハイレベルブロック図である。
【図３】メモリプールのマネージメントのためのシステムの例示的なハイレベルアーキテクチャを示す図である。
【図４】メモリプール３１０のマネージメントのための例示的なクラス階層を示す図である。
【図５】ラスタ化での例示的なメモリの割り当てを説明するためのスナップショットを示す図である。
【図６】メモリプール３１０からの新しいブロックの割り当てのためのアルゴリズムの例示的なフローチャート７００である。
【図７】割り当てられたブロックへのポインタを取得するために例示的な方法で実行されるステップを説明するフローチャートである。
【図８】割り当てられるべき適切なメモリプールと、対応するオブジェクトとを決定する例示的な所定のルーチン７３０のフローチャートである。
【発明を実施するための形態】
【００１０】
本発明の種々の特徴を反映する実施形態によれば、第１の印刷可能データから生成される第２の形式すなわち中間形式の印刷可能データの自動的な保存、操作、および処理のシステムおよび方法が示される。いくつかの実施形態では、第１の印刷可能データは文書のＰＤＬ記述の形式をとることがあり、中間印刷可能データはＰＤＬ記述から生成されるオブジェクトのディスプレイリストの形式をとることがある。
【００１１】
図１は、本発明のいくつかの実施形態によって文書を印刷するためのシステムにおける構成要素を示すブロック図である。図１に示すように、本発明と整合性を有するコンピュータソフトウェアアプリケーションはコンピュータのネットワークで展開することができ、このネットワークは、従来の通信プロトコルおよび／またはデータポートインターフェースを使って情報が交換されることを可能にする通信リンクを介して接続されている。
【００１２】
図１に示すように、例示的なシステム１００には、演算装置１１０とサーバ１３０とを含む複数のコンピュータが備えられる。さらに演算装置１１０とサーバ１３０とはコネクション１２０を通して交信し、コネクションはネットワーク１４０を通る。ネットワーク１４０は、一例ではインターネットとすることもできる。演算装置１１０はコンピュータワークステーション、デスクトップコンピュータ、ラップトップコンピュータ、またはネットワーク環境で使用することのできる他の演算装置とすることができる。サーバ１３０は、演算装置１１０およびその他の装置（図示しない）へ接続することのできるプラットフォームとすることができる。演算装置１１０とサーバ１３０とは、プリンタ１７０を使った文書の印刷を可能にするソフトウェア（図示しない）を実行することができる。
【００１３】
例示的なプリンタ１７０は電子データから物理文書を生成する装置を含んでおり、この装置にはレーザープリンタ、インクジェットプリンタ、ＬＥＤプリンタ、プロッタ、ファクシミリ装置、およびディジタルコピー機が包含されるが、これらに限定されない。いくつかの実施形態では、プリンタ１７０は、演算装置１１０またはサーバ１３０からコネクション１２０を介して受信した文書を直接印刷することもできる。いくつかの実施形態においては、このような構成は、演算装置１１０またはサーバ１３０による追加の処理を伴って（またはこれを伴わずに）、文書の直接印刷を可能にする。いくつかの実施形態においては、文書はテキスト、図形、および画像のうちの１つ以上を含む。いくつかの実施形態においては、プリンタ１７０は印刷用の文書のＰＤＬ記述を受信することができる。また、文書印刷処理を分散させることもできることに留意されたい。よって、演算装置１１０、サーバ１３０、および／またはプリンタ１７０は、文書がプリンタ１７０によって物理的に印刷される前に、ハーフトーニング、カラーマッチング、および／またはその他の操作プロセスといった文書印刷処理の部分を実行し得る。
【００１４】
また演算装置１１０は着脱可能型メディアドライブ１５０も含む。着脱可能型メディアドライブ１５０には、例えば、３．５インチフロッピードライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＯＭドライブ、ＣＤ±ＲＷもしくはＤＶＤ±ＲＷドライブ、ＵＳＢフラッシュドライブ、および／または本発明の実施形態と整合性を有する他の着脱可能型メディアドライブなどが含まれ得る。いくつかの実施形態においては、ソフトウェア・アプリケーションの一部は、着脱可能型メディアに存在していてもよく、また、着脱可能型メディアドライブ１５０を使用して演算装置１１０によって読み取られ、実行される。
【００１５】
コネクション１２０は、演算装置１１０とサーバ１３０とプリンタ１７０とを接続するものであり、従来の通信プロトコルおよび／またはデータポートインターフェースを使った有線または無線の接続として実施され得る。一般にコネクション１２０は、装置間のデータの伝送を可能にする任意の通信路とすることができる。一実施形態では、例えば各装置は、パラレルポート、シリアルポート、イーサネット（商標）、ＵＳＢ、ＳＣＳＩ、ＦＩＲＥＷＩＲＥ（商標）、および／または適切な接続を介したデータ伝送用の同軸ケーブルポートといった、従来のデータポートを備える。いくつかの実施形態においては、コネクション１２０は、ディジタル加入者線（ＤＳＬ）、非対称ディジタル加入者線（ＡＤＳＬ）、またはケーブル接続とすることができる。通信リンクは無線リンクでも、有線リンクでも、様々な装置間の通信を可能とする本発明の各実施形態と整合性を有する任意の組み合わせとすることもできる。
【００１６】
ネットワーク１４０はローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、またはインターネットを含んでいてもよい。いくつかの実施形態においては、ネットワーク１４０を介して送られる情報は、送信されるデータのセキュリティを確保するために暗号化することができる。プリンタ１７０はコネクション１２０を介してネットワーク１４０へ接続することができる。いくつかの実施形態においては、プリンタ１７０は演算装置１１０および／またはサーバ１３０へ直接接続される。またシステム１００は、本発明のいくつかの実施形態によれば、他の周辺機器（図示しない）を含んでいてもよい。本発明と整合性を有するコンピュータソフトウェアアプリケーションは、図１に示すように、例示的コンピュータおよびプリンタのいずれに配備されていてもよい。例えば、演算装置１１０は、サーバ１３０から直接ダウンロードされるソフトウェアを実行することもできる。これらのアプリケーションの各部分は、本発明のいくつかの実施形態に従って、プリンタ１７０によって実行されても良い。
【００１７】
図２に例示的なプリンタ１７０のハイレベルなブロック図を示す。いくつかの実施形態においては、プリンタ１７０は、ＣＰＵ１７６、ファームウェア１７１、メモリ１７２、入出力ポート１７５、印刷エンジン１７７、および補助記憶装置１７３を接続するバス１７４を含む。またプリンタ１７０は、本発明のいくつかの実施形態によれば、ＰＰＭＬを処理するためのアプリケーションの一部分を実行することのできるその他の特定用途向け集積回路（ＡＳＩＣ）、および／またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）１７８を含んでいてもよい。いくつかの実施形態では、プリンタ１７０は、入出力ポート１７５およびコネクション１２０を使って２次記憶メモリまたは演算装置１１０内のその他のメモリにアクセスすることもできる。いくつかの実施形態では、プリンタ１７０は、プリンタオペレーティングシステムおよび他の適切なアプリケーションソフトウェアを含むソフトウェアを実行することもできる。いくつかの実施形態においては、プリンタ１７０は、他のオプションのうち、用紙サイズ、排紙トレイ、色選択、および印刷解像度をユーザ設定可能なものにすることができる。
【００１８】
いくつかの実施形態では、ＣＰＵ１７６は、汎用プロセッサとすることも、専用プロセッサとすることも、組み込みプロセッサとすることもできる。ＣＰＵ１７６は、制御情報および命令を含むデータをメモリ１７２および／またはファームウェア１７１と交換することができる。メモリ１７２は、ＳＤＲＡＭやＲＤＲＡＭといった任意の種類のダイナミックランダムアクセスメモリ（ＤＲＡＭ）とすることができるが、これらには限定されない。ファームウェア１７１は、起動シーケンス、事前定義のルーチン、およびその他のコードを含む命令およびデータを保持するが、これらには限定されない。いくつかの実施形態では、ファームウェア１７１の中のコードおよびデータは、ＣＰＵ１７６によって処理される前にメモリ１７２へコピーされる。ファームウェア１７１に含まれるルーチンには、演算装置１１０から受け取られるページ記述をディスプレイリストおよび画像バンドへ変換するためのコードを含めることができる。いくつかの実施形態においては、ファームウェア１７１には、ディスプレイリストにおける表示コマンドを適切なラスタ化ビットマップへ変換するとともに当該ビットマップをメモリ１７２の中に記憶するためのラスタ化ルーチンが含まれても良い。また、ファームウェア１７１には、圧縮ルーチンおよびメモリマネージメントルーチンが含まれていてもよい。いくつかの実施形態においては、ファームウェア１７１内のデータおよび命令をアップグレード可能とすることもできる。
【００１９】
いくつかの実施形態においては、ＣＰＵ１７６が命令およびデータに従って動作し、ＡＳＩＣＳ／ＦＰＧＡＳ１７８および印刷エンジン１７７に制御およびデータを提供して印刷文書を生成する。いくつかの実施形態においては、ＡＳＩＣＳ／ＦＰＧＡＳ１７８が印刷エンジン１７７に制御およびデータを提供する。またＦＰＧＡＳ／ＡＳＩＣＳ１７８は、変換、圧縮、およびラスタ化のアルゴリズムのうちの１つ以上を実施してもよい。いくつかの実施形態においては、演算装置１１０が文書データを第１の印刷可能データに変換することができる。次いで第１の印刷可能データを、中間印刷可能データに変換するためにプリンタ１７０に送ることができる。プリンタ１７０は、中間印刷可能データを最終形態の印刷可能データに変換して、この最終形態に従って印刷を行う。いくつかの実施形態においては、第１の印刷可能データは、文書のＰＤＬ記述に該当する。いくつかの実施形態では、文書のＰＤＬ記述から、一連のよりローレベルなプリンタ特有コマンドを有する上記最終形態の印刷可能データへの変換処理には、オブジェクトのディスプレイリストを有する中間印刷可能データの生成が含まれている。
【００２０】
いくつかの実施形態では、ディスプレイリストには、テキスト、図形、および画像のデータオブジェクトの１つ以上が保有されていてもよい。いくつかの実施形態では、ディスプレイリストの中のオブジェクトは、ユーザ文書の中の類似オブジェクトに対応していてもよい。いくつかの実施形態では、ディスプレイリストは、中間印刷可能データの生成を支援することができる。いくつかの実施形態では、ディスプレイリストは、メモリ１７２あるいは補助記憶装置１７３の中に記憶することができる。例示的な補助記憶装置１７３は、内部あるいは外部のハードディスク、メモリスティック、あるいはシステム２００に使用することのできる他の記憶装置であってよい。いくつかの実施形態では、上記ディスプレイリストは、プリンタ１７０、演算装置１１０、およびサーバ１３０の１つ以上に存在していてもよい。ディスプレイリストを記憶するためのメモリは、開示された実施形態によれば、専用メモリであってもよく、または、汎用メモリの一部を形成してもよく、または、専用メモリと汎用メモリのある種の組み合わせでもよい。いくつかの実施形態では、メモリは、複数のディスプレイリストを必要に応じて保有するために動的（dynamically）に割り当てることができるようになっている。いくつかの実施形態では、複数のディスプレイリストを記憶するために割り当てられたメモリは、処理の後に動的に解放（released）されるようになっている。
【００２１】
図３はメモリプールのマネージメントのためのシステムの例示的なハイレベルアーキテクチャを示している。図３に示されているように、言語サーバ３４０、エンジンサーバ３６０、およびラスタサーバ３２０は、互いに通信することができる。加えて、言語サーバ３４０、エンジンサーバ３６０、およびラスタサーバ３２０は、ルーチンを呼び出すとともにＲＤＬライブラリ３３０と通信することができる。このシステムは、ラスタサーバ３２０、エンジンサーバ３６０、およびメモリマネージメントアプリケーションプログラミングインターフェイス（ＡＰＩ）３７０と通信するフレームバッファマネージメントライブラリ３３５をさらに含んでもよい。いくつかの実施形態では、メモリマネージャ３７５によって提供される機能性（functionality）の使用は、メモリマネージメントアプリケーションプログラミングインターフェイス（ＡＰＩ）３７０を介して行われてもよい。メモリマネージャ３７５はメモリマネージメントＡＰＩ３７０の機能（functions）を定義する。いくつかの実施形態では、フレームバッファライブラリ３３５内のコードのように、ディスプレイリストおよびフレームバッファ３５０に関係があるコードは、メモリマネージメントＡＰＩ３７０を介してメモリマネージャ３７５と接続する（intreface）。したがって、これらの実施形態では、メモリマネージャは、ディスプレイリストまたはフレームバッファをマネージメントおよび／または操作するために使用されるプログラムコードを変更することなく、プロダクト固有のメモリマネージャによって置き換えられるか、または修正され得る。いくつかの実施形態では、ディスプレイリストは、印刷されるべき文書内、または印刷されるべき文書におけるページ内でのデータオブジェクトと、これらデータオブジェクトのコンテキストとを定義するコマンドを含んでもよい。これらの表示コマンドには、文字あるいはテキスト、ラインドローイングあるいはベクトル、及び、画像あるいははラスタデータを有するデータが含まれていてもよい。
【００２２】
いくつかの実施形態では、ディスプレイリストは、動的に再構成することのできるものであり、また、再構成可能型ディスプレイリスト（ＲＤＬ）と呼ばれる。１つの実施形態では、或るディスプレイリストオブジェクトが動的に操作できる態様で記憶されるデータ構造を使用して、ＲＤＬを実施することができる。例えば、画像オブジェクトは、利用可能なメモリの量を増大させるために適切に圧縮されてもよく、また、参照されかつ／または使用されるときに復元されてもよい。いくつかの実施形態では、ＲＤＬはまた、ＲＤＬオブジェクトの実際の記憶場所へのポインタ、オフセット値（offsets）、あるいはアドレスを保持することでＲＤＬオブジェクトをメモリおよび／または補助記憶装置に記憶させることができ、その後、ＲＤＬオブジェクトが参照されかつ／または使用されるときにこの実際の記憶場所が検索される。一般に、ＲＤＬによれば、ディスプレイリストオブジェクトは、順応性を伴って記憶することができるとともに、システムの制約条件およびパラメータに基づいて操作することができる。
【００２３】
１つの実施形態では、文書のＰＤＬ記述をディスプレイリストおよび／またはＲＤＬ表示へ変換することは、ＲＤＬライブラリ３３０およびメモリマネージャ３７５の中のルーチンを用いて言語サーバ３４０によって実行することができる。例えば、言語サーバ３４０は、ＰＤＬ言語基本要素を受け取り、かつ、これらのＰＤＬ言語基本要素をデータおよび図形オブジェクトに変換し、さらに、ＲＤＬライブラリ３３０およびメモリマネージャ３７５の中の関数によってもたらされる機能を用いて、再構成可能なディスプレイリストへこれらデータおよび図形オブジェクトを追加することができる。いくつかの実施形態では、メモリマネージャ３７５の中の関数およびルーチンへのアクセスは、メモリマネージメントＡＰＩ３７０を通してもたらされる。いくつかの実施形態では、ディスプレイリストは、例示的なメモリプール３２０のような、動的に割り当てられたメモリプールの中において、記憶され、操作される。このメモリプールは、メモリ１７２の一部であってもよい。
【００２４】
いくつかの実施形態では、ＲＤＬを作成することは、実際の印刷に先立つデータの処理における中間ステップであってもよい。ＲＤＬは、変換される前に、その後の形態（a subsequent form）に構文解析される。いくつかの実施形態では、その後の形態は最終表示であってもよく、また、変換処理はデータのラスタ化と呼ばれることがある。いくつかの実施形態では、フレームバッファマネージメントライブラリ３３５内のルーチンを使用してラスタ化はラスタサーバ３２０によって実行されてもよい。ラスタ化の際に、ラスタ化されたデータは、メモリマネージメントＡＰＩ３７０を介してアクセスされるメモリマネージャ３７５内のルーチンを使用して、メモリプール３１０の一部分であるフレームバッファ３５０内に保存されてもよい。いくつかの実施形態では、ラスタ化されたデータは、印刷ページに付けられるマークを指定するビットマップの形態を採ることができる。
【００２５】
一実施形態では、メモリマネージャ３７５内のルーチンは、メモリ１７２内における利用可能なメモリのいくつかのサブセットをメモリプール３１０として管理し、メモリマネージメントＡＰＩ３７０を介して、要求されている処理にメモリプール３１０中からメモリを割り当ててもよい。いくつかの実施形態では、メモリマネージャ３７５は、メモリマネージメントＡＰＩ３７０と相互作用し、メモリマネージャ３７５によって提供される機能へのアクセスがメモリマネージメントＡＰＩ３７０を介して行われる。要求されている処理によってメモリがもはや必要とされないときには、メモリは、割り当て解除されてメモリプール１３０へ戻り、他の処理に利用可能なものとなることができる。いくつかの実施形態では、メモリマネージャ３７０内のルーチンには、メモリ解放へのルーチン（routines to free memory）、メモリ回復へのルーチン（routines to recover memory）、およびメモリを補助記憶装置１７３へスワップすることのできるスワッピングルーチンが包含される他のさまざまなメモリマネージメントルーチンもまた含まれている。いくつかの実施形態では、フレームバッファ３５０はメモリプール３１０の一部分でもよく、メモリマネージャ３７０によって管理されてもよい。たとえば、フレームバッファマネージメントライブラリ３３５内の関数への呼び出しは、メモリマネージメントＡＰＩ３７０内の関数への呼び出しをもたらすことがある。その後に、メモリマネージメントＡＰＩは、メモリマネージャ３７０内の１つ以上の関数を呼び出すことがある。メモリマネージャ３７５によって行われた動作の結果は、呼び出し側プロセスへ送られる（be routed back to）ことがある。一実施形態では、フレームバッファ３５０は、メモリの一次連続ブロック（an initial contiguous block）へ割り当てられてもよく、また、その後のメモリブロックは、要求されたときにフレームバッファ３５０へ割り当てられてもよい。メモリブロックは、他のフレームバッファ目的のためにメモリプール３１０から割り当てられてもよい。いくつかの実施形態では、フレームバッファ３５０またはその他の処理に割り当てられた異なるメモリブロックによって、メモリ１７２内の非連続な記憶場所が占領される。
【００２６】
印刷エンジン１７７は、フレームバッファライブラリ３３５内のルーチンを使用して、ラスタ化されたデータをフレームバッファ３５０の中で処理し、用紙のような印刷媒体の上にページの印刷可能画像を形成することができる。いくつかの実施形態では、ラスタサーバ３２０およびエンジンサーバ３６０はまた、これらの機能を実行するために、ＲＤＬライブラリ３３０の中のルーチンを使用することができる。いくつかの実施形態では、エンジンサーバ３６０は、印刷エンジン１７７へ制御情報、指示、およびデータを提供することができる。いくつかの実施形態では、エンジンサーバ３６０は、メモリプール３２０へ返却するための処理後に、フレームバッファライブラリ及びメモリマネージメントＡＰＩ３７０を介してメモリマネージャ３７５によって提供される機能を使用して、ディスプレイリストオブジェクトによって使用されたメモリを解放させるルーチンを呼び出すことがある。いくつかの実施形態では、ＲＤＬメモリプールの一部および／またはフレームバッファ３５０は、メモリ１７２あるいは補助記憶装置１７３の中に存在していてもよい。いくつかの実施形態では、言語サーバ３４０、ラスタサーバ３２０、およびエンジンサーバ３６０のためのルーチンはファームウェア１７１の中に設けられてもよく、あるいは、ＡＳＩＣＳ／ＦＰＧＡＳ１７８を使用して実施されてもよい。
【００２７】
図４は、ラスタ化中にメモリプールをマネージメントするシステムの例示的なオブジェクト指向型実施における例示的なクラス図５００の一部を示している。このクラス構造は、永続的な（persistent）単体のｍｍ主制御装置５１０を含む。ｍｍ主制御装置５１０を永続的な単体として宣言することによって、ｍｍ主制御装置５１０の単一インスタンスがあるということと、ｍｍ主制御装置５１０の同一性がコード実行中に変化しないということと、ｍｍ主制御装置５１０へのアクセスの大域包括的な箇所（a global point of access to Master Control）があるということが保証される。クラス、サブクラス、および／またはオブジェクト５２０〜５６０によって、ラスタ化中のメモリマネージメントのためのシステムの一つの実施が示されている。さまざまなクラスに属しているオブジェクトは、実行中にインスタンス化することができる。
【００２８】
図４に示されているように、ｍｍ主制御装置５１０は、クラスｍｍプール５６０の３つのオブジェクトを含む。これらのオブジェクトは、ノードオブジェクト、ブロックオブジェクト、およびスーパーブロックオブジェクトを有する。これらのｍｍプールオブジェクトは、共有されたメモリプール３１０のマネージメントにおいて使用され得る。たとえば、メモリプール３１０は、スーパーブロックプール５６０−１、ノードプール５６０−２、およびブロックプール５６０−３を有すると論理的にみなされ得る。したがって、スーパーブロックプール５６０−１、ノードプール５６０−２、およびブロックプール５６０−３は、メモリプール３１０のサブプールである。さらに、各サブプールは当該サブプールにローカルな（local to that sub-pool）オブジェクトを有する可能性がある。オブジェクトと共に「ローカル」という用語を使用することは、記述的な目的のためにオブジェクトとそれぞれのプールとを関連付けるだけのために役立つ。したがって、スーパーブロックオブジェクトはスーパーブロックプール５６０−１にローカルでもよく、ノードオブジェクトはノードプール５６０−２にローカルでもよく、ブロックオブジェクトはブロックプール５６０−３にローカルでもよい。たとえば、フレームバッファ３５０と関連付けられたフレームバッファマネージメントライブラリ３３５内のルーチンは、メモリマネージメントＡＰＩ３７０を介してメモリマネージャ３７５を使用し、スーパープール５６０−１にスーパーブロックを要求することが可能である。同様に、ＲＤＬによってブロックオブジェクトがブロックプール５６０−３に要求されることがある。ｍｍノードオブジェクト５３０は、ブロック割り当ておよびスーパーブロック割り当てをマネージメントする要求時に、ノードプール５６０−２からメモリマネージャ５７５によって割り当てられ得る。一実施形態では、１つのｍｍノードオブジェクト５３０は、ブロックの割り当て毎、或いはスーパーブロックの割り当て毎に使用されてもよい。いくつかの実施形態では、１つずつの個別のオブジェクトは、メモリの離散的な連続セクションを含んでもよい。
【００２９】
いくつかの実施形態では、ｍｍ主制御装置５１０は、ｍｍ優先度つきキューオブジェクト（PriorityQueue object）５５０を含むことができる。図４に示されているように、ｍｍ優先度つきキューオブジェクト５５０はｍｍリストオブジェクト５４０を含むことができる。さらに、ｍｍリストオブジェクト５４０は、ｍｍリンクオブジェクト５２０を使用してｍｍノードオブジェクト５３０を保持する。いくつかの実施では、ｍｍノードオブジェクト５３０は、割り当て済みのブロックまたはスーパーブロックのそれぞれの経過を追う（keeps track）。ｍｍ優先度つきキューオブジェクト５５０はスワップ可能なブロックの経過を追うために使用され得る。利用可能なメモリが少なく、スワッピングが使用可能であるとき、ｍｍ優先度つきキューオブジェクト５５０は、メモリからブロックをスワップする順序を決定するために使用され得る。たとえば、割り当て済みブロックは優先度と関連付けられ得る。たとえば、優先度は、ブロックをアクセスしやすい状態に保つことで得られる性能優位性の指標である場合がある。一実施形態では、ｍｍ優先度つきキューオブジェクト５５０は、優先度の増加する順序にオブジェクトを順序付け、これによって、低優先度ブロックが高優先度ブロックよりも先にスワップアウトされることを可能にすることがある。その他の関数およびルーチンは、１つ以上の高優先度のメモリチャンクを瞬時にアクセスできる形式に保つために優先番号を使用することがある。
【００３０】
図５は、ラスタ化でのメモリプール３１０の例示的な割り当てを説明するためのスナップショット６００を示している。ラスタ化中の様々な時点で、メモリプール３１０は、空きスーパーブロック６３０、割り当て済みスーパーブロック６３０−２、空きブロック６１０−１および割り当て済みブロック６１０−２にのいくつかの組み合わせを含むことがある。論理的な観点から、メモリプール３１０は、最初は空きスーパーブロック６３０−１、ノードブロック、および空きブロック６１０−１の集まりであると考えてもよい。いくつかの実施形態では、全てのスーパーブロックオブジェクトは、一様な一定サイズでもよい。いくつかの実施形態では、ブロックオブジェクトもまた一様な一定サイズでもよい。いくつかの実施形態では、ブロックオブジェクトの一様な一定サイズは、スーパーブロックオブジェクトのサイズより小さく、スーパーブロックオブジェクトのサイズと異なる。いくつかの実施形態では、スーパーブロックオブジェクトのサイズはブロックオブジェクトのサイズの整数倍でもよい。いくつかの実施形態では、スーパーブロックオブジェクトのサイズはブロックオブジェクトのサイズの偶数倍でもよい。たとえば、図５に示されているように、スーパーブロック６３０のサイズは４つのブロック６１０のサイズと等しくてもよい。
【００３１】
例えばビットマップを保存するためなど、フレームバッファ３５０による使用のためにメモリが要求されるときには、スーパーブロック６３０−１が割り当てられ得る。ＲＤＬのため、または一時的な保存および処理の目的のためにメモリが要求されるときには、より小さい単位のメモリが割り当てられ得る。たとえば、空きスーパーブロック６３０−１は等しいサイズのブロック６１０に分割されることができ、これらのブロック６１０の１つがＲＤＬのため、または、一時的な保存および処理の目的のために使用されるときに割り当てられ得る。スーパーブロックプール５６０−１、ノードプール５６０−２、およびブロックプール５６０−３の使用は、一つには、メモリ割り当ての細かさ（granularity）を制御することを可能にする。ノードプール５６０−１およびブロックブール５６０−３は、スーパーブロックプール５６０−１からのメモリを割り当てるときに増大することができる。いくつかの実施形態では、メモリプール３１０内でばらばらに散在するブロックから新しいスーパーブロックを作成するために、メモリデフラグルーチンは、周期的に、または、利用可能なメモリがある種の閾値より少ないときに用いられ、或いは、メモリを解放するストラテジーとして用いられることがある。
【００３２】
図６は、メモリプール３１０から新しいブロック６１０−１を割り当てるアルゴリズムの例示的なフローチャート７００を示している。ステップ７１０において、アルゴリズムが呼び出される。次に、所定のルーチン７３０において、新しいノードオブジェクトがノードプール５６０−２から割り当てられる。いくつかの実施形態では、新しいオブジェクトのためのメモリの割り当ては、新しい要素を割り当てる一般的な（generic）所定のルーチンを使用して実行されることがある。所定のルーチン７３０は、適切なメモリプール５６０と、割り当てられるべき対応オブジェクトとを決定するために、供給されるパラメータを使用することがある。たとえば、所定のルーチン７３０は、ノードプール５６０−２から新しいノードを割り当ててもよい。ステップ７４０において割り当てが成功であると判定される場合には、異なるパラメータのセットと共に所定のルーチン７３０を使用して、新しいスーパーブロック６３０−１又はブロック６１０−１が割り当てられてもよい。たとえば、メモリがビットマップを保存するためにフレームバッファ３５０によって使用中である場合には、所定のルーチン７３０はスーパーブロックプール５６０−３から新しいスーパーブロック６３０−１を割り当てることがある。ステップ７６０において割り当てが成功であると判定される場合には、新たに割り当てられるブロック６１０−２がノードに割り当てられ、当該ノードはステップ７７０において優先度つきキューに収容されることがある。いくつかの実施形態では、ノードはｍｍ優先度つきキューオブジェクト５５０にリンクされてもよい。所定のルーチン７３０を使用した割り当てが失敗である場合には、アルゴリズムはステップ７８０へ進み、「割り当て失敗」メッセージが呼び出し側ルーチンへ返送されてもよい。
【００３３】
図７は、割り当て済みブロック６１０−２へのポインタを取得するための例示的な方法で実行されるステップを示すフローチャート８００である。ステップ８１０において、アルゴリズムが呼び出される。次に、ステップ８２０において、割り当て済みブロック６１０−２に対応するノードが決定され得る。ステップ８３０および８４０においてそれぞれ判定されるように、ブロック６１０−２がメモリ内に存在し、ブロック６１０−２に対応するノードの参照カウントが「０」である場合には、ステップ８５０において、ノードが優先度つきキューから削除されることがある。いくつかの実施形態では、ノードを削除するために適切な動作がｍｍ優先度つきキューオブジェクト５５０で実行されることがある。
【００３４】
ステップ８３０において判定され得るように、ブロック６１０−２がメモリ内に存在しない場合には、所定のルーチン７３０は供給されるパラメータを使用し、適切なメモリプール５６０と、割り当てられるべき、対応するスーパーブロック又はブロックオブジェクトとを決定することができる。次に、ステップ８８０において判定され得るように、オブジェクトの割り当てが成功の場合には、ブロック６１０−２のためのデータが補助記憶装置１７３から読み出されるか、またはスワップインされ、アルゴリズムはステップ８６０へ進む。ステップ８４０において、ノードの参照カウントが零でない場合には、アルゴリズムはステップ８６０へ進むことができる。ステップ８６０において、ノードの参照カウントが１つ増加され、ブロック６１０−２へのポインタが返却されることがある。ステップ８８０において所定のルーチン７３０によるメモリの割り当てが失敗であると判定される場合には、ステップ８９５において「メモリ不足」メッセージが呼び出し側ルーチンへ返送される。
【００３５】
図８は、適切なメモリプールと、割り当てられるべき対応オブジェクトとを決定する例示的な所定のルーチン７３０のフローチャートを示している。ステップ９１０において、アルゴリズムが呼び出される。次に、ステップ９２０において、使用されるべきサブプールが決定される。いくつかの実施形態では、サブプールは、スーパーブロックプール５６０−１でもよく、または、ノードプール５６０−２とブロックプール５６０−３との一方でもよい。割り当て要求がスーパーブロックプール５６０−１に対して行われると、ステップ９３０において、スーパーブロックプール５６０−１内のスーパーブロック６３０−１の可用性が決定され得る。スーパーブロック６３０−１が利用可能である場合には、ステップ９４０においてスーパーブロック６３０−１が割り当てられ得る。たとえば、スーパーブロック６３０−１は、フレームバッファ３５０と関連付けられたルーチンに割り当てられることがある。
【００３６】
ノードプール５６０−２またはブロックプール５６０−３に対してブロック６１０−１の要求が行われる場合には、ステップ９６５において、ノードプール５６０−２またはブロックプール５６０−３における空き、もしくは割り当てられていない要素又は割り当てユニットについての可用性が決定され得る。ノードオブジェクトまたはブロック６１０−１が利用可能である場合には、ステップ９７０において、要求されるオブジェクトのタイプに基づいてノードオブジェクトまたはブロック６１０−１が割り当てられ得る。たとえば、ノードオブジェクトがメモリマネージャ３７５による内部使用のために割り当てられてもよい。ステップ９６５における可用性のチェックによってノードプール５６０−２またはブロックプール５６０−３内に空き要素または割り当てられていない要素が存在しないと判定される場合には、アルゴリズムはステップ９３０へ進む。ステップ９３０において、スーパーブロックプール５６０−１内のスーパーブロック６３０−１の可用性が判定され得る。スーパーブロック６３０−１が利用可能である場合には、ステップ９４０においてスーパーブロックはブロック６１０−１に分割され、適切なプール５６０−２または５６０−３に割り当てられ得る。たとえば、スーパーブロック６３０−１はブロック６１０−１に分割され、１つのブロック６１０−１がＲＤＬに割り当てられてもよい。
【００３７】
スーパーブロックプール５６０−１内に利用可能なスーパーブロック６３０−１が存在しない場合には、ステップ９６０において、アルゴリズムは、複数のメモリ解放ストラテジーのうちの一つを呼び出すことができる。たとえば、このアルゴリズムは、メモリが別のプロセスによって解放されるまで待機することができる。いくつかの実施形態では、アルゴリズムは、低優先度のノードを優先度つきキューから補助記憶装置１７３にスワップすることがある。メモリ解放ストラテジーが失敗の場合には、アルゴリズムは、メモリ不足を呼び出し側プロセスに報告することがある。
【００３８】
本発明の他の実施形態は、本明細書の考察、及び、本明細書中に開示された本発明の１つ以上の実施形態の実施により、当業者にとって明らかになるであろう。明細書及び例は例示的なものに過ぎないことを意図しており、本発明の本来の範囲及び要旨は、以下の特許請求の範囲に示されるものである。
【符号の説明】
【００３９】
１００ システム
１１０ 演算装置
１２０ コネクション
１３０ サーバ
１４０ ネットワーク
１５０ 着脱可能型メディアドライブ
１７０ プリンタ
１７１ ファームウェア
１７２ メモリ
１７３ 補助記憶装置
１７４ バス
１７５ 入出力ポート
１７６ ＣＰＵ
１７７ 印刷エンジン
１７８ ＦＰＧＡ
３１０ メモリプール
３２０ ラスタサーバ
３３０ ＲＤＬライブラリ
３３５ フレームバッファマネージメントライブラリ
３４０ 言語サーバ
３５０ フレームバッファ
３６０ エンジンサーバ
３７０ メモリマネージメントアプリケーションプログラミングインターフェイス
３７５ メモリマネージャ
５１０，５２０，５３０，５４０，５５０，５６０ オブジェクト
５６０−１ スーパーブロックプール
５６０−２ ノードプール
５６０−３ ブロックプール
６００ メモリレイアウト
６１０−１ 空きブロック
６１０−２ 割り当て済みブロック
６３０−１ 空きスーパーブロック
６３０−２ 割り当て済みスーパーブロック
【特許請求の範囲】
【請求項１】
フレームバッファメモリおよびディスプレイリストメモリを備える単一のメモリプールをマネージメントする方法であって、
前記単一のメモリプールは、
複数のスーパーブロックオブジェクトを有するスーパーブロックプールと、
複数のノードオブジェクトを有するノードプールと、
複数のブロックオブジェクトを有するブロックプールと、
を含むサブプールを備え、
当該方法は、
前記サブプールのうちの少なくとも１つへ向けられたメモリ割り当て要求を受信するステップと、
前記メモリ要求を満たすためにローカルオブジェクトが前記サブプール内で利用可能である場合に、前記メモリ要求内で識別された前記サブプールにローカルなオブジェクトを割り当てるステップと、
前記メモリ要求が前記ノードプールまたは前記ブロックプールへ向けられており、前記メモリ要求を満たすために各サブプール内に利用可能なローカルオブジェクトが存在しない場合に、前記スーパーブロックプールからのオブジェクトを割り当てるステップと、
いずれの前記サブプール内にも利用可能な空きオブジェクトが存在しない場合に、複数のメモリ解放ストラテジーのうちの少なくとも１つを適用するステップと、
を備える方法。
【請求項２】
前記スーパーブロックプールが整数個の均一サイズのスーパーブロックオブジェクトを備え、
前記ブロックプールが整数個の均一サイズのブロックオブジェクトを備え、
前記スーパーブロックオブジェクトのサイズが前記ブロックオブジェクトのサイズの整数倍である請求項１に記載の方法。
【請求項３】
前記スーパーブロックオブジェクトのサイズが前記ブロックオブジェクトのサイズの偶数倍である請求項２に記載の方法。
【請求項４】
前記複数のメモリ復旧ストラテジーが、
割り当て済みのメモリ常駐ブロックオブジェクトが解放されるのを待機するステップと、
前記ノードプールおよび前記ブロックプールのうちの少なくとも一方をデフラグするステップと、
メモリ常駐ブロックオブジェクトを補助記憶装置に保存するステップと、
のうちの少なくとも１つを備える請求項１に記載の方法。
【請求項５】
前記スーパーブロックの前記サイズが複数の所定のサイズのうちの１つから選択される請求項１に記載の方法。
【請求項６】
前記単一のメモリプールが印刷装置に常駐する請求項１に記載の方法。
【請求項７】
メモリ常駐ブロックオブジェクトが補助記憶装置に保存される順序は、当該メモリ常駐ブロックオブジェクトに対応するノードオブジェクトと関連付けられた優先度に基づく請求項４に記載の方法。
【請求項８】
アプリケーションプログラミングインターフェイスを使用して呼び出される請求項１に記載の方法。
【請求項９】
フレームバッファメモリの要求が前記スーパーブロックプールへ向けられる請求項１に記載の方法。
【請求項１０】
ディスプレイリストメモリの要求が前記ブロックプールへ向けられる請求項１に記載の方法。
【請求項１１】
複数の命令を記憶するコンピュータ可読媒体であって、
前記複数の命令は、プロセッサによって実行されると、フレームバッファメモリおよびディスプレイリストメモリを備える単一のメモリプールをマネージメントする方法を実行するものであり、
前記単一のメモリプールは、
複数のスーパーブロックオブジェクトを有するスーパーブロックプールと、
複数のノードオブジェクトを有するノードプールと、
複数のブロックオブジェクトを有するブロックプールと、
を含むサブプールを備え、
前記方法は、
前記サブプールのうちの少なくとも１つへ向けられたメモリ割り当て要求を受信するステップと、
前記メモリ要求を満たすためにローカルオブジェクトが前記サブプール内で利用可能である場合に、前記メモリ要求内で識別された前記サブプールにローカルなオブジェクトを割り当てるステップと、
前記メモリ要求が前記ノードプールまたは前記ブロックプールへ向けられており、前記メモリ要求を満たすために各サブプール内に利用可能なローカルオブジェクトが存在しない場合に、前記スーパーブロックプールからのオブジェクトを割り当てるステップと、
いずれの前記サブプール内にも利用可能な空きオブジェクトが存在しない場合に、複数のメモリ解放ストラテジーのうちの少なくとも１つを適用するステップと、
を備えるコンピュータ可読媒体。
【請求項１２】
前記スーパーブロックプールが整数個の均一サイズのスーパーブロックオブジェクトを備え、
前記ブロックプールが整数個の均一サイズのブロックオブジェクトを備え、
前記スーパーブロックオブジェクトのサイズが前記ブロックオブジェクトのサイズの整数倍である請求項１１に記載のコンピュータ可読媒体。
【請求項１３】
前記スーパーブロックオブジェクトのサイズが前記ブロックオブジェクトのサイズの偶数倍である請求項１２に記載のコンピュータ可読媒体。
【請求項１４】
前記複数のメモリ復旧ストラテジーが、
メモリ常駐ブロックオブジェクトが解放されるのを待機するステップと、
前記ノードプールおよび前記ブロックプールのうちの少なくとも一方をデフラグするステップと、
メモリ常駐ブロックオブジェクトを補助記憶装置に保存するステップと、
のうちの少なくとも１つを備える請求項１１に記載のコンピュータ可読媒体。
【請求項１５】
前記メモリプールが印刷装置に常駐する請求項１１に記載のコンピュータ可読媒体。
【請求項１６】
メモリ常駐ブロックオブジェクトが補助記憶装置に保存される順序は、当該メモリ常駐ブロックオブジェクトに対応するノードオブジェクトと関連付けられた優先度に基づく請求項１４に記載のコンピュータ可読媒体。
【請求項１７】
前記方法がアプリケーションプログラミングインターフェイスを使用して呼び出される請求項１１に記載のコンピュータ可読媒体。
【請求項１８】
複数の命令を記憶するコンピュータ可読メモリであって、
前記複数の命令は、プロセッサによって実行されるとき、フレームバッファメモリおよびディスプレイリストメモリを備える単一のメモリプールをマネージメントする方法を実行するものであり、
前記単一のメモリプールは、
複数のスーパーブロックオブジェクトを有するスーパーブロックプールと、
複数のノードオブジェクトを有するノードプールと、
複数のブロックオブジェクトを有するブロックプールと、
を含むサブプールを備え、
前記方法は、
前記サブプールのうちの少なくとも１つへ向けられたメモリ割り当て要求を受信するステップと、
前記メモリ要求を満たすためにローカルオブジェクトが前記サブプール内で利用可能である場合に、前記メモリ要求内で識別された前記サブプールにローカルなオブジェクトを割り当てるステップと、
前記メモリ要求が前記ノードプールまたは前記ブロックプールへ向けられており、前記メモリ要求を満たすために一つ一つの前記サブプール内に利用可能なローカルオブジェクトが存在しない場合に、前記スーパーブロックプールからのオブジェクトを割り当てるステップと、
いずれの前記サブプール内にも利用可能な空きオブジェクトが存在しない場合に、複数のメモリ解放ストラテジーのうちの少なくとも１つを適用するステップと、
を備えるコンピュータ可読メモリ。
【請求項１９】
前記スーパーブロックプールが整数個の均一サイズのスーパーブロックオブジェクトを備え、
前記ブロックプールが整数個の均一サイズのブロックオブジェクトを備え、
前記スーパーブロックオブジェクトのサイズが前記ブロックオブジェクトのサイズの整数倍である請求項１８に記載のコンピュータ可読メモリ。
【請求項２０】
前記複数のメモリ復旧ストラテジーが、
メモリ常駐ブロックオブジェクトが解放されるのを待機するステップと、
前記ノードプールおよび前記ブロックプールのうちの少なくとも一方をデフラグするステップと、
メモリ常駐ブロックオブジェクトを補助記憶装置に保存するステップと、
のうちの少なくとも１つを備える請求項１に記載の方法。
【請求項１】
フレームバッファメモリおよびディスプレイリストメモリを備える単一のメモリプールをマネージメントする方法であって、
前記単一のメモリプールは、
複数のスーパーブロックオブジェクトを有するスーパーブロックプールと、
複数のノードオブジェクトを有するノードプールと、
複数のブロックオブジェクトを有するブロックプールと、
を含むサブプールを備え、
当該方法は、
前記サブプールのうちの少なくとも１つへ向けられたメモリ割り当て要求を受信するステップと、
前記メモリ要求を満たすためにローカルオブジェクトが前記サブプール内で利用可能である場合に、前記メモリ要求内で識別された前記サブプールにローカルなオブジェクトを割り当てるステップと、
前記メモリ要求が前記ノードプールまたは前記ブロックプールへ向けられており、前記メモリ要求を満たすために各サブプール内に利用可能なローカルオブジェクトが存在しない場合に、前記スーパーブロックプールからのオブジェクトを割り当てるステップと、
いずれの前記サブプール内にも利用可能な空きオブジェクトが存在しない場合に、複数のメモリ解放ストラテジーのうちの少なくとも１つを適用するステップと、
を備える方法。
【請求項２】
前記スーパーブロックプールが整数個の均一サイズのスーパーブロックオブジェクトを備え、
前記ブロックプールが整数個の均一サイズのブロックオブジェクトを備え、
前記スーパーブロックオブジェクトのサイズが前記ブロックオブジェクトのサイズの整数倍である請求項１に記載の方法。
【請求項３】
前記スーパーブロックオブジェクトのサイズが前記ブロックオブジェクトのサイズの偶数倍である請求項２に記載の方法。
【請求項４】
前記複数のメモリ復旧ストラテジーが、
割り当て済みのメモリ常駐ブロックオブジェクトが解放されるのを待機するステップと、
前記ノードプールおよび前記ブロックプールのうちの少なくとも一方をデフラグするステップと、
メモリ常駐ブロックオブジェクトを補助記憶装置に保存するステップと、
のうちの少なくとも１つを備える請求項１に記載の方法。
【請求項５】
前記スーパーブロックの前記サイズが複数の所定のサイズのうちの１つから選択される請求項１に記載の方法。
【請求項６】
前記単一のメモリプールが印刷装置に常駐する請求項１に記載の方法。
【請求項７】
メモリ常駐ブロックオブジェクトが補助記憶装置に保存される順序は、当該メモリ常駐ブロックオブジェクトに対応するノードオブジェクトと関連付けられた優先度に基づく請求項４に記載の方法。
【請求項８】
アプリケーションプログラミングインターフェイスを使用して呼び出される請求項１に記載の方法。
【請求項９】
フレームバッファメモリの要求が前記スーパーブロックプールへ向けられる請求項１に記載の方法。
【請求項１０】
ディスプレイリストメモリの要求が前記ブロックプールへ向けられる請求項１に記載の方法。
【請求項１１】
複数の命令を記憶するコンピュータ可読媒体であって、
前記複数の命令は、プロセッサによって実行されると、フレームバッファメモリおよびディスプレイリストメモリを備える単一のメモリプールをマネージメントする方法を実行するものであり、
前記単一のメモリプールは、
複数のスーパーブロックオブジェクトを有するスーパーブロックプールと、
複数のノードオブジェクトを有するノードプールと、
複数のブロックオブジェクトを有するブロックプールと、
を含むサブプールを備え、
前記方法は、
前記サブプールのうちの少なくとも１つへ向けられたメモリ割り当て要求を受信するステップと、
前記メモリ要求を満たすためにローカルオブジェクトが前記サブプール内で利用可能である場合に、前記メモリ要求内で識別された前記サブプールにローカルなオブジェクトを割り当てるステップと、
前記メモリ要求が前記ノードプールまたは前記ブロックプールへ向けられており、前記メモリ要求を満たすために各サブプール内に利用可能なローカルオブジェクトが存在しない場合に、前記スーパーブロックプールからのオブジェクトを割り当てるステップと、
いずれの前記サブプール内にも利用可能な空きオブジェクトが存在しない場合に、複数のメモリ解放ストラテジーのうちの少なくとも１つを適用するステップと、
を備えるコンピュータ可読媒体。
【請求項１２】
前記スーパーブロックプールが整数個の均一サイズのスーパーブロックオブジェクトを備え、
前記ブロックプールが整数個の均一サイズのブロックオブジェクトを備え、
前記スーパーブロックオブジェクトのサイズが前記ブロックオブジェクトのサイズの整数倍である請求項１１に記載のコンピュータ可読媒体。
【請求項１３】
前記スーパーブロックオブジェクトのサイズが前記ブロックオブジェクトのサイズの偶数倍である請求項１２に記載のコンピュータ可読媒体。
【請求項１４】
前記複数のメモリ復旧ストラテジーが、
メモリ常駐ブロックオブジェクトが解放されるのを待機するステップと、
前記ノードプールおよび前記ブロックプールのうちの少なくとも一方をデフラグするステップと、
メモリ常駐ブロックオブジェクトを補助記憶装置に保存するステップと、
のうちの少なくとも１つを備える請求項１１に記載のコンピュータ可読媒体。
【請求項１５】
前記メモリプールが印刷装置に常駐する請求項１１に記載のコンピュータ可読媒体。
【請求項１６】
メモリ常駐ブロックオブジェクトが補助記憶装置に保存される順序は、当該メモリ常駐ブロックオブジェクトに対応するノードオブジェクトと関連付けられた優先度に基づく請求項１４に記載のコンピュータ可読媒体。
【請求項１７】
前記方法がアプリケーションプログラミングインターフェイスを使用して呼び出される請求項１１に記載のコンピュータ可読媒体。
【請求項１８】
複数の命令を記憶するコンピュータ可読メモリであって、
前記複数の命令は、プロセッサによって実行されるとき、フレームバッファメモリおよびディスプレイリストメモリを備える単一のメモリプールをマネージメントする方法を実行するものであり、
前記単一のメモリプールは、
複数のスーパーブロックオブジェクトを有するスーパーブロックプールと、
複数のノードオブジェクトを有するノードプールと、
複数のブロックオブジェクトを有するブロックプールと、
を含むサブプールを備え、
前記方法は、
前記サブプールのうちの少なくとも１つへ向けられたメモリ割り当て要求を受信するステップと、
前記メモリ要求を満たすためにローカルオブジェクトが前記サブプール内で利用可能である場合に、前記メモリ要求内で識別された前記サブプールにローカルなオブジェクトを割り当てるステップと、
前記メモリ要求が前記ノードプールまたは前記ブロックプールへ向けられており、前記メモリ要求を満たすために一つ一つの前記サブプール内に利用可能なローカルオブジェクトが存在しない場合に、前記スーパーブロックプールからのオブジェクトを割り当てるステップと、
いずれの前記サブプール内にも利用可能な空きオブジェクトが存在しない場合に、複数のメモリ解放ストラテジーのうちの少なくとも１つを適用するステップと、
を備えるコンピュータ可読メモリ。
【請求項１９】
前記スーパーブロックプールが整数個の均一サイズのスーパーブロックオブジェクトを備え、
前記ブロックプールが整数個の均一サイズのブロックオブジェクトを備え、
前記スーパーブロックオブジェクトのサイズが前記ブロックオブジェクトのサイズの整数倍である請求項１８に記載のコンピュータ可読メモリ。
【請求項２０】
前記複数のメモリ復旧ストラテジーが、
メモリ常駐ブロックオブジェクトが解放されるのを待機するステップと、
前記ノードプールおよび前記ブロックプールのうちの少なくとも一方をデフラグするステップと、
メモリ常駐ブロックオブジェクトを補助記憶装置に保存するステップと、
のうちの少なくとも１つを備える請求項１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００９−２４５４３７（Ｐ２００９−２４５４３７Ａ）
【公開日】平成２１年１０月２２日（２００９．１０．２２）
【国際特許分類】
【外国語出願】
【出願番号】特願２００９−８１５１９（Ｐ２００９−８１５１９）
【出願日】平成２１年３月３０日（２００９．３．３０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（５０７０３１９１８）コニカ ミノルタ システムズ ラボラトリー， インコーポレイテッド (157)
【Ｆターム（参考）】
【公開日】平成２１年１０月２２日（２００９．１０．２２）
【国際特許分類】
【出願番号】特願２００９−８１５１９（Ｐ２００９−８１５１９）
【出願日】平成２１年３月３０日（２００９．３．３０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（５０７０３１９１８）コニカ ミノルタ システムズ ラボラトリー， インコーポレイテッド (157)
【Ｆターム（参考）】
[ Back to top ]