JP3772996B2 - 実際ワーキング・セット決定システム - Google Patents
実際ワーキング・セット決定システム Download PDFInfo
- Publication number
- JP3772996B2 JP3772996B2 JP00650896A JP650896A JP3772996B2 JP 3772996 B2 JP3772996 B2 JP 3772996B2 JP 00650896 A JP00650896 A JP 00650896A JP 650896 A JP650896 A JP 650896A JP 3772996 B2 JP3772996 B2 JP 3772996B2
- Authority
- JP
- Japan
- Prior art keywords
- page
- memory
- data
- working set
- transactions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3428—Benchmarking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/12—Replacement control
- G06F12/121—Replacement control using replacement algorithms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3414—Workload generation, e.g. scripts, playback
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/805—Real-time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/87—Monitoring of transactions
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/953—Organization of data
- Y10S707/955—Object-oriented
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、一般的にはマルチタスク環境における仮想メモリの管理に関するもので、特に、プロセスのワーキング・セットに必要なＲＡＭを減少させるシステムおよび方法に関するものである。
【０００２】
【従来の技術】
長年にわたってシステムＲＡＭの要求量は指数的に増大してきた。例えば、初期のＰＤＰ−１１ミニコンピュータは、わずか６４ＫＢ(キロ・バイト)のＲＡＭでＵｎｉｘを実行した。初期のワークステーションの中には、ハードウエア上最大２ＭＢ（メガ・バイト）に限定されるものもあった。今日では、最新のデスクトップ・ソフトウェアを実行させるとき、１６ＭＢをもつエントリ・レベルのワークステーションでさえ遅く見えることがある。
【０００３】
従来行われてきたメモリ対策の１つは、メモリ使用調整を不要のものとして退け、ＲＡＭを単に増設するというものである。結局、ＲＡＭ価格は下落し続けるが、システム価格もまた下落し続ける。ＲＡＭの必要性の相対的比率の増大を所与とすれば、ＲＡＭ価格が減少し、システム価格が減少しても、ＲＡＭはシステム費用の主要部分を占めることに変わりはない。加えて、今日の競争環境において、あるソフトウェアが一層多くのＲＡＭを必要とし、その結果、他のソフトウエアより高価なシステムを必要とすれば、そのソフトウエアの営業担当者はその販売に苦労することとなる。
【０００４】
従来技術の解決策は、主として仮想メモリのページング・アルゴリズムを改善することに焦点を集めてきた。その例のいくつかを、Gupta、Franklin両氏著の IEEE, Transactions on Computers C-27-706-712 (1978)、Levy、Lipman両氏著のComputer 15:35-41 (1982)および Loreti、Deitel両氏著のOperating Systems, Addison-Wesley, Reading, MA (1981)で参照することができる。これらの従来技術の改良は、大きいプログラムを一層効率的に実行させることを可能にしている点において重要ではあるが、それらはメモリ使用の継続的増加を考慮に入れてない。従って、最も先進的ページング・アルゴリズムをもってしても、プロセスが増大し続けるにつれ、システムＲＡＭ要求は増加し続ける。
【０００５】
【発明が解決しようとする課題】
しかしながら、ＲＡＭを増設しても、この追加ＲＡＭの多くが付加機能によって消費される一方で、その多くが貧弱なプログラミング実施の結果としてただ浪費されている。種々の技術を使用して、浪費されたＲＡＭの返還をめざしメモリ調整の努力が払われたが、明確な成功は得られてない。この不成功は、従来技術のシステムにおけるメモリ調整機構が、特定のプロセスのワーキング・セットの構成内容に関し十分な洞察を行う能力に欠けていることによる。従って、ある１つのプロセスによって頻繁に利用されるＲＡＭの量を減少させることによって浪費されるＲＡＭの回収をメモリ調整機構が可能にするシステムが必要とされている。
【０００６】
【課題を解決するための手段】
本発明によって、プロセスのデータ構造利用度に関する情報を提供する対話型情報記録および処理ツールが提供される。この情報は、プロセスの動的に割当てられるメモリのワーキング・セット（すなわちメモリ上の作業領域）を減少させるために使われる。本発明が提供する「実際ワーキング・セット」（Actual Working Setの頭文字をとって以下ＡＷＳと呼称する場合もある）決定機構は、システムを改良するアプローチでなく、所与のプロセスが効率的に動作するようにプロセス自体を改善するために必要な情報をメモリ調整機構に与えることによって仮想メモリ問題へ対処するというアプローチをとる。
【０００７】
本発明は、どの部分が頻繁に使用されるか、すなわち、プロセスの仮想メモリ（Virtual Memoryの頭文字をとって以下ＶＭと呼称する場合もある）のワーキング・セット（仮想メモリ・ワーキング・セットVirtual Memory Woroking Setをその頭文字をとって以下ＶＷＳと呼称する場合もある）と呼ばれる動的に割当てられるページが実際にどれほど使われるかを決定する。プロセスが頻繁に使用する実際のメモリは、プロセスの実際ワーキング・セット（ＡＷＳ）と呼ばれる。
【０００８】
本発明は、所与のベンチマークを実行して、動的に割当てられるメモリの実際ワーキング・セットを決定する。ＡＷＳ決定機構の基本的アプローチは、対象とされるプロセスが厳しいスラッシュ状態（すなわち、頻繁なページ・フォールトのためプロセスの実行が極度に停滞する状態）のとき、どのデータ構造がページ・フォールトをひき起こすかを観察することである。本発明には、データ記録機構およびデータ分析機構が含まれる。データ記録機構は、最も正確な結果が得られるように一貫したベンチマークが行われることを保証し、目標プロセスに関するヒープ・ページ・フォールトの数と細分性を増加させてプロセッサのページ・フォールト・メカニズムが関連データ構造のアクセス回数を通算することを可能にし、すべてのヒープ・ページ・フォールトおよびトランザクションを記録する。
【０００９】
データ分析機構は、ベンチマーク実行の間データ記録機構によって記録された大量のデータを効率的に処理する対話型情報処理ツールである。データ分析機構は、また、ユーザが処理されたデータを対話モードで活用し、プロセスのヒープＡＷＳを精密に分析することを可能にする。データ分析機構は、ヒープ・メモリの各ブロックを特定のＣ言語データ構造に関係づける。ベンチマークが完了し、上述の情報が記録され、関係づけられた後、該情報の処理ステップが実行され、対象とされたプロセスのヒープＡＷＳが決定される。
【００１０】
【発明の実施の形態】
Ｉ. はじめに
本発明は、プロセスのデータ構造の活用度に関する情報を提供する対話型記録ツールおよび処理ツールを提供する。この情報は、動的に割当てられるプロセスのメモリのワーキング・セットを減少させるために使われる。本発明の実施形態について、以下、システム概要、仮想メモリおよびワーキング・セット理論の簡単な考察、動的割当てプロセスのメモリの実際ワーキング・セットの認定、最後に、事例研究の順に説明する。
【００１１】
II. システムの概要
図１は、本発明の好ましい実施形態であるコンピュータ・システム１００を示すブロック図である。図１は、ＵＮＩＸシステム・カーネルであり、種々のモジュールとその相互関係を示す。特に、図１は、ＵＮＩＸシステム・カーネル１０８の２つの主要コンポーネントである、ファイル・サブシステム１０２およびプロセス制御サブシステム１０４を示す。いくつかのモジュールが他のモジュールの内部動作と相互に作用するので実際のカーネルはモデルと異なるが、図１は、ＵＮＩＸシステムの論理的側面を観察するのに役立つ。
【００１２】
図１は、コンピュータ・システム１００の３つのレベル、すなわち，ユーザ・レベル１０６、カーネル・レベル１０８およびハードウェア・レベル１１０を示す。システム呼び出しインターフェース１１２およびライブラリ・インターフェース１１４は、アプリケーション・プログラム１１６とカーネル１０８の間の境界を表す。システム呼び出しは、Ｃプログラムにおける通常の関数呼び出しと同様であり、ライブラリはオペレーティング・システムに入るために必要とされるプリミティブへこれらの関数呼出しを対応づける。しかし、アセンブリ言語プログラムが、システム呼び出しライブラリなしで直接システム呼び出しを起動するために使われることもある。プログラムは、しばしば標準入出力ライブラリのような他のライブラリを使用してシステム呼び出しの一層高度な使用を行う。ライブラリは、コンパイル時にプログラムにリンクされ、アプリケーション・プログラムの一部となる。
【００１３】
図１では、システム呼び出しのセットは、ファイル・サブシステム１０２と対話するものとプロセス制御サブシステム１０４と対話するものに区分されている。ファイル・サブシステム１０２は、ファイルを管理し、ファイル空間を割り当て、空き空間を管理し、ファイルへのアクセスを制御し、ユーザに代わってデータを取り出す。プロセスは、従来技術において既知のシステム呼び出しの特定のセットを介してファイル・サブシステム１０２と対話する。
【００１４】
ファイル・サブシステム１０２は、カーネル・レベル１０８と補助メモリとして図示されている補助記憶装置１３８との間のデータの流れを制御するバッファ・キャッシュ１１８を使用して、ファイル・データにアクセスする。バッファ・キャッシュ１１８は、ブロックＩ／Ｏデバイス・ドライバ１２４と対話して、カーネル１０８との間でのデータ転送を始動させる。デバイス・ドライバは、周辺装置の動作を制御するカーネル・モジュールである。ブロックＩ／０装置１２４は、ランダム・アクセス記憶装置であるか、または、そうでない場合、デバイス・ドライバによって、システム１００の残りの装置にとってランダム・アクセス記憶装置であるように見えるようにされる。例えば、テープ駆動装置は、カーネル１０８がランダム・アクセス記憶装置としてテープ装置を読み取ることを可能にする。ファイル・サブシステム１０２は、また、バッファ・キャッシュ１１８の干渉なしに「生の」Ｉ／０デバイス・ドライバと直接対話する。生のデバイスは、しばしば文字デバイス・ドライバ１２２と呼ばれ、ブロック・デバイス・ドライバ１２４以外のすべてのデバイスを含む。ほとんどのブロック装置１２４は、また、文字デバイス・インターフェースを提供し、カーネル１０８をバッファ・キャッシュ１１８へバイパスさせることを可能にする。これは、ブロック装置への「生のＩ／０」と呼ばれる。文字デバイス１２２とブロックＩ／Ｏ装置１２４を合わせたものがデバイス・ドライバ１２０を構成する。
【００１５】
プロセス制御サブシステム１０４は、プロセス間通信１３０、メモリ管理１３４、およびプロセス同期／スケジューリング１３２に対して責任を持つ。ファイル・サブシステム１０２およびプロセス制御サブシステム１０４は、実行のためメモリにファイルをロードするとき、相互に対話し、プロセス制御サブシステム１０４は、実行する前にメモリに実行可能ファイルを読み込む。プロセス制御サブシステム１０４は、プロセスを制御するため既知のシステム呼び出しを実行する。
【００１６】
メモリ管理モジュール１３４は、メモリの割り当てを制御する。システムがすべてのプロセスのために十分な物理メモリを有していないならば、カーネル１０８は、すべてのプロセスが公正な機会を得るように、主メモリ１３６と補助メモリ１３８の間でそれらプロセスを移動させる。一般的に、メモリを管理するため、スワップと要求ページングという２つの方策がある。スワップ・プロセスは、プロセスに対するメモリの割り当てを「スケジュール」して、ＣＰＵスケジューラの動作に影響を及ぼすので、スケジューラ１３２と呼ばれることがある。
【００１７】
スケジューラ・モジュール１３２は、ＣＰＵをプロセスに割り当てる。スケジューラ・モジュール１３２は、資源を待つ間プロセスが自発的にＣＰＵを放棄するまで、または、プロセスの最近の実行時間がある時間量を越える時カーネルがプロセスに対し優先実行を開始するまで、プロセスを順番に実行させるようにスケジュールする。次に、スケジューラ１３２は、実行させる最優先順位を持つプロセスを選択する。元のプロセスが、実行可能な最優先順位を持つプロセスである場合再び実行する。プロセス間通信１３０には、事象の非同期信号からプロセス間の同期メッセージ伝送におよぶいくつかの形態がある。
【００１８】
最後に、ハードウェア制御１４０は、割込みを処理し、ハードウェア・レベルと通信する機能を果たす。ハードウェア・レベル１１０は、プロセッサ１４２、システム・メモリまたは主メモリ１３６およびシステム・バス１４４を備える。主メモリ１３６は、好ましくは、ランダム・アクセス・メモリ（すなわちＲＡＭ）である。プロセッサ１４２の適切な形態の１つは、既知のＩＢＭ社製ＲＩＳＣＳｙｓｔｅｍ／６０００コンピュータ・ファミリである。好ましくは、プロセッサ１４２は、ヒューレット・パッカード社ＰＡ‐ＲＩＳＣＳｙｓｔｅｍである。しかしながら、本発明の範囲と精神を逸脱することなく、その他のコンピュータを代替的に使用することは可能である。
【００１９】
ハードウェア・レベル１１０には、Ｉ／Ｏバス１４６に接続した、補助記憶装置１３８、ディスプレイ装置１４８、およびキーボードまたはマウス等のユーザ・インタフェース装置１５０を含む数多くの周辺装置がさらに含まれる。補助記憶装置１３８は、例えば、ハードディスク・ドライブやフロッピーディスク・ドライブを含む。加えて、ユーザ・インタフェース１５０へのユーザ入力を記録し、ディスプレイ装置１４８に表示し、次に、Ｉ／Ｏバス１４６を経由して直接再生するため記録／再生装置１５２が使われる。プロセスの実行中に、ディスクまたはターミナルのような装置は、ＣＰＵへの割り込みを行うかもしれない。そのような場合、カーネルは割り込みを処理した後割り込まれたプロセスの実行を再開する。割り込みは、専用プロセスによって処理されることはなく、現在実行中のプロセスの範囲に呼び出されているカーネルの特殊機能によって処理される。
【００２０】
カーネル１０８の適切な形態は、米国ニュージャージー州マレイ・ヒル所在のAT&T Bell Laboratoriesによって開発されたAT&T Unix System V、および米国カリフォルニア州バークレイ所在のカリフォルニア大学バークレイ校によって開発されたBerkeley Software Distribution (BSD) Unix systemなどのような既知の、一般に使用されているＵｎｉｘシステムである。特定のアプリケーションまたは機械のために構成されたこれらＵｎｉｘシステムのバリエーションも使用可能である。そのような構成には、米国コロラド州フォート・コリンズ所在のヒューレット・パッカード社が開発した、本発明の好ましい実施形態であるＨＰ‐ＵＸＵｎｉｘオペレーティング・システムが含まれる。
【００２１】
III. 仮想記憶装置と従来のワーキング・セット・モデル
コンピュータ・システム１００は、仮想メモリ・システムである。図２は、物理的メモリと仮想メモリの間の関係を図示する。図２では、主メモリ１３６における物理メモリは、物理的ページ２０２として図示されている。仮想メモリ（ＶＭ）システムは、主メモリ１３６が実際より大きい数の物理的ページ２０２を保持する容量を持つかのような錯覚をコンピュータ・プロセスに与える。従って、コンピュータ・システム１００において動作するあらゆるプロセスは、システムに実装された主メモリ１３６の物理的メモリ（ＲＡＭ）量１３６より非常に大きい仮想アドレス空間２０４を持つことができる。ＶＭシステムは、複雑な形態でこの錯覚を与える。
【００２２】
仮想および物理両アドレス空間は、ページと呼ばれる小さい構成要素２０６に分割される。ページ２０６のサイズは、典型的には、２−３ＫＢである。各ページは、実際には、ＲＡＭ（主メモリ１３６）または補助記憶装置１３８のようなスワップ空間２０６に置かれる。メモリ・マネージャ１３４は、各仮想ページ２０８とその実際の位置の間のマッピング（すなわち対応関係）を維持する。このマッピングの一部は、ＣＰＵ１４２内の特別なメモリ管理ハードウェアに記憶される。各仮想メモリのアクセスは、このメモリ管理ハードウェアを経由する。メモリ位置のページがＲＡＭ１３６に位置づけられていれば、物理的メモリ２０２の正確な物理アドレスが、メモリ・アクセスのために使われる。仮想メモリ位置のページがスワップ空間２０６に位置するならば、メモリ・アクセスが起きる前に、ページをＲＡＭ１３６にロードするためページ・フォールトが発生する。
【００２３】
ＲＡＭ１３６がいっぱいのときは、あるページがＲＡＭに呼び込まれる前に別のページがスワップ空間２０６に送り出されなければならない。現在メモリにあるページが「ページ・アウト」または「スワップ・アウト」される。メモリ管理モジュール１３４は、スワップ・アウトすべきページ２１０を公平な方法で決定するようにつとめる。一般的に、上述のページ活動を実行する時間は、プロセッサ１４２の処理速度に比較して長い。正確な時間は、スワップ・ディスクとコンピュータの相対的速度のような種々の因子に依存するが、ページ処理の時間が長いため、あるプロセスがページ・フォールトに遭遇すると当該ページのＲＡＭ１３６への書き込みが終了するまでそのプロセスは中断される。
【００２４】
例えば、コンピュータ・システム１００が６４ＫＢの物理メモリ２０２のＲＡＭ１３６を持ち、各ページのサイズが４ＫＢであるとすると、システムは１６個のページからなる物理メモリ２０２を持つこととなる。あるプロセスが１２８ＫＢの仮想メモリを利用する場合、それは３２個のページからなる仮想メモリを持つ。プロセスが１７番目のページの中のアドレスをアクセスしようとする時点でプロセスの最初の１６個のページがＲＡＭ１３６にロードされているとすれば、メモリ管理モジュール１３４は、１７番目のページのアクセスに関してページ・フォールトを発生させる。スワップ空間２０６から１７番目のページをページ・インさせるため、ＲＡＭ１３６にある最初の１６個のページの１つがスワップ空間２０６へスワップ・アウトされなければならない。
【００２５】
プロセスが同一の１６個のページ内に大部分のメモリ・アクセスを保持していれば、ページ・フォールトはほとんど発生せず、従って処理速度はすぐれている。しかし、プロセスがラウンドロビン方式（すなわち巡回方式）で３２個のページすべてをアクセスするならば、それは殆どの時間中断される。このような事態が発生すると、プロセスはスラッシュ(thrash)状態であるといわれる。殆どの活動的プロセスが過剰なページングに遭遇すると、システムはスラッシュ状態であるといわれる。「活動的」プロセスがほとんどの時間中断されるので、ほどんど進展は見られない。
【００２６】
好ましい実施形態のＨＰ−ＵＸオペレーティング・システムのような最近のマルチタスク・オペレーティング・システムは複雑な仮想メモリ管理システムを使用する。第１に、カーネルは、いくつかのプロセスを同時にタイム・スライスすることを試みるので、コンピュータのＲＡＭのすべてを１つのプロセスに割り当てることはない。ＲＡＭは、複数のプロセスに使われる仮想ページを含む。第２に、最近のカーネルは、ページ・フォールトの数を減らすため高度のアルゴリズムを使う。例えば、ＨＰ−ＵＸカーネルは、特定のページ・フォールトが発生すると、直後にアクセスされる場合に備えて周辺のページを同時にページ・インすべきか否かを判断する。カーネルは、また、スワップすべきページ（例えば再度すぐに呼び込まれる可能性のないページ）を決定するため種々の基準を保持する。カーネルは、プロセスのワーキング・セットに使われているメモリをけっしてページ・アウトしない。
【００２７】
P. J. Denning氏によって"Communications of the ACM 11:323-333 (1968)"および"IEEE Transactions on Software Engineering SE-6:64-84 (1980)"で紹介されているワーキング・セット・モデルは、マルチ・オペレーティング・システムにおけるＶＭ動作を理解するのに役立つ。ワーキング・セット・モデルを支持する基本的概念は、プロセスがその（複数）ページのサブセットを頻繁にアクセスすることである。これらのページは、プロセスのワーキング・セット（すなわち実働セット）と呼ばれる。ワーキング・セットのページは、プロセスがスラッシュ状態にならないようにメモリに常駐したままでいなければならない。
【００２８】
ある１つのプロセスのワーキング・セットは、時間の経過とともに変化する傾向がある。例えば、起動時におけるプロセスのワーキング・セットは、安定状態のワーキング・セットより非常に大きくまた非常に異なっていることがある。また、メニュ選択型プログラムのワーキング・セットは、ユーザが異なるメニュ項目を選択するにつれて変化する可能性がある。
【００２９】
すべてのプロセスの仮想メモリのサイズが使用可能ＲＡＭの範囲内でまかなえる場合は、プロセスが最初のページをアクセスするときにのみページ・フォールトは発生する。そのような場合ではシステム処理能力はスラッシュに苦しむことはない。スラッシシュ状態は、すべての活動プロセスのワーキング・セットの総和が使用可能ＲＡＭを越えるとき発生する。そのような状況では、１つのプロセスのワーキング・セットのページ・インを行うために、別のプロセスのワーキング・セットがページ・アウトされなければならない。
【００３０】
プロセスがスラッシュ状態であることをカーネルが検出すると、カーネルは劇的対応策を開始する。例えば、カーネルは全体のプロセスをスワップ・アウトして残りの１つまたは複数のプロセスのために使用可能なページの数を増加させることがある。当然のことながら、スワップ・アウトされたプロセスが最後に再び実行される場合、それらのワーキング・セットのページのすべては呼び込まれなければならず、そのためその他のプロセスはスワップ・アウトされる。上述のように、システム処理能力を向上させスラッシシュの発生確率とその悪影響を減少させるため、ＶＭページング・アルゴリズムに対し種々の改善が提案されてきた。しかしながら、上述のように、これらの改善は、メモリ使用の継続的な増加を考慮に入れていない。
【００３１】
IV. 実際ワーキング・セット（ＡＷＳ）の決定
Ａ．本発明のワーキング・セット・モデル
上記説明において、「ワーキング・セット」という用語は、特に仮想メモリ・システム・ページ２０４を指すものとして使われた。これは、伝統的に仮想メモリの改善に焦点が当てられてきたことによる。伝統的改善は、メモリ管理モジュール１３４によって実行されるページング機能に集中している。これは、おそらく、常駐プロセスがオペレーティング・システムの作成者以外の製造業者によって作成されることによる。しかし、本発明のシステムおよび方法は、メモリ管理モジュール１３４を改善するというよりもむしろプロセス自体を改善し、それによって所与のプロセスが一層効率的に動作することを意図する。この異なる見解とアプローチを実現するため、当業界において使われる伝統的な定義を検討しなければならない。
【００３２】
図３を参照すれば、非ワーキング・セット・メモリを調整してもシステム処理能力は改善されないことは十分理解されるであろう。例えば、上記で説明した例および図３を参照して、プロセスのサイズ全体は３２個のページのままで、ワーキング・セットが１７個のページ（例えば、ページ１−１７）であると仮定し、システム・メモリ１３６はなお１６個のページだけを備えているとすれば、従来技術のワーキング・セット・モデルに従えば、コンピュータ・システム１００はスラッシュする。ワーキング・セットにない８個のページ（例えばページ２５ないし３２）を追い出すというメモリ調整努力は、なお、システム１００をスラッシュさせる。これは、排除されるページのいずれもワーキング・セットにないためである。このように、プロセスの１／４がページ・アウトされても、システム１００はなおスラッシュする。その代わり、ワーキング・セット・ページの１つ（例えばページ１７）がワーキング・セットから除かれれば、コンピュータはもはやスラッシュしない。
【００３３】
本発明に従うプロセスのワーキング・セットの定義を図４を参照しながらここで説明する。メモリ管理モジュール１３４の観点からすれば、全体ページ４０２が、そのプロセスのワーキング・セットであるが、プログラムはそのページの一部を使用しているだけかもしれない。従って、本発明においては、頻繁に使用され、または動的に割当てられるページを、プロセスの仮想メモリ（ＶＭ）ワーキング・セット（ＶＷＳ、Virtual Working Set）と呼ぶ。プロセスが頻繁に使用する実際のメモリをプロセスの実際ワーキング・セット（Actual Working Setの頭文字をとって以下ＡＷＳと呼称する場合もある）４０６と呼ぶ。典型的にはメモリ調整はＣおよびFortranのような高級言語を利用して実行されるので、ＡＷＳ４０６は、プロシージャおよびデータ構造を用いて表現される。ＶＷＳ（伝統的なワーキング・セット）４０４はページとして表現される。すなわち、データ構造またはコードは、特定ページの小さい部分４０６を利用する。
【００３４】
ほとんどの状況において、ＡＷＳ４０６は、ＶＷＳ４０４より常に小さい。これは、細分性が相違しているからである。ＡＷＳ４０６の細分性は、バイト単位で測られ、一方ＶＷＳ４０４は、各ページのサイズ（典型的には２、３ＫＢ）で常に測られる。本発明は、サイズにおけるこの相違を活用して、仮想メモリ・ワーキング・セット４０４のどの部分が実際ワーキング・セット４０６に含まれるかを決定する。
【００３５】
図３に関連した上述の例を参照して、ＶＷＳ４０４は１７ページであって、そのうちプログラム・コードが１ページ（例えば最初のページ）を占め、プログラムは２つのセットの変数に常時アクセスすると仮定する。さらに、第１の変数セットは２番目のページの約１／２を占め、第２の変数セットは、１６個のエレメントからなる結合リストであると仮定する。なお、上記リストにおいて、各エレメントのサイズは２４バイトであり、エレメントのそれぞれは、上記第２のページの後半から始まって別のページに記録されていると仮定する。
【００３６】
この特定のケースにおいて、本発明は、ＡＷＳ４０６として実際に使われるＶＷＳ４０４の部分だけを考慮する。この例において頻繁にアクセスされる特定のデータ構造は相対的に非常に小さい。ＡＷＳ４０４もそれに応じて小さい。この情報によって、プログラマは結合リストが２番目のページ内にだけ収納されるようにプログラムを慎重に設計することができるであろう。そのようなケースでは、ＶＷＳ４０４は、１７ページではなくわずか２ページとなる。これはＡＷＳ４０６のサイズに一層近くなる。
【００３７】
Ｂ．本発明の好ましいメモリ調整
メモリ調整は、当該プロセスのＶＷＳを減少させるプロセスであるとみなされる。スラッシュの原因となるプロセスに対してメモリ調整が行われれば、スラッシュは減じられるか、除去される。典型的には、メモリ調整は、以下のタイプのタスクの１つまたは複数を実行するものとして一般的に説明される。すなわち、(1)局地性の改善、(2)ヒープ断片化の減少 、(3)メモリ漏洩の除去、(4)コードおよびデータ構造のサイズの減少、(5)メモリの再使用、および(6)ワーキング・セット増大のスケジュール化、である。
【００３８】
局地性の改善に関しては、相対的に小さく、かつ異なるページにまたがって存在する項目への頻繁なアクセスは、ＶＷＳを（上述のように）不必要に増大させる。可能な限り項目を隣接して割り当てることによって、（サイズ的にＡＷＳへ近似した）より小さいＶＷＳとなり、ページ・フォールトの発生が少なくなる。この規則は、データにもコードにもあてはまる。例えば、頻繁に使われるプロシージャをグループ化すれば、コードのＡＷＳを減らすことができる。（ＨＰ−ＵＸと連係するコンパイラなど）コンパイラによっては、コードに関してこの作業を自動的に行う。
【００３９】
ヒープ断片化は、未使用の穴を累積して放置する形態でメモリを割り当て解放する場合に発生する。断片化はＡＷＳの局地性を減らし、そのため不必要にＶＷＳを増大させる。メモリ漏洩は、割当てられたメモリがもはや使われないのにかかわらず解放されない場合に発生する。メモリ漏洩も、ＡＷＳの局地性を減らし、そのため不必要にＶＷＳを増大させる。
【００４０】
コードおよびデータ構造のサイズを減らす目的は、ＡＷＳおよびＶＷＳを縮小することである。例えば、ある構造が、いくつかのブーリアン値の各々に関し複数の３２ビット・フィールドを含むとすれば、その代わりに、１ビットのフィールドからなるグループを使用することができる。１６ビット整数フィールドを３２ビット整数の代わりにあてることができる場合が多い。使用頻度の少ないコード／データを頻繁に使われるコード／データの中から引き出すことができる場合が多い（例えば、ＸサーバのＷｉｎｄｏｗＯｐｔＲｅｃ）。
【００４１】
メモリの再使用は、システム処理能力を向上させる。例えば、プロシージャが起動される毎に、１つまたは複数の一時的項目を割り当て、使用し、次に、解放すると仮定する。一旦項目を割り当て、将来の使用に備えて周囲に保持することによって、ヒープ断片化は減少する（このため他のヒープ・データ構造に対する局地性を改善することができる）。
【００４２】
ワーキング・セット増大のスケジュール化は、また、システム処理能力を向上させる。例えば、プロセスのＶＷＳは、起動時に大きいことが多い。同時にいくつかのプロセスを起動させることは、一時的なスラッシング状態の誘因となる。プロセスの起動を同期化させることによって、ワーキング・セットの大きさの総和がスラッシュを引き起こす程の大きさにはならないであろう。これはシステム・レベルの例ではあるが、同様の例をコードについても観察することができる。
【００４３】
上述の諸改善を効果的に成し遂げるため、本発明は、プロセスのプログラムの開発に用いたものと同じ高級言語プロシージャおよびデータ構造で表される当該プロセスのＡＷＳを決定する。上述のように、本発明は、データ記録およびデータ分析機構を実行する。図５は、本発明の好ましい実施形態のブロック図である。図５に示されるように、本発明のＡＷＳ決定機構５００は、データ記録機構５０２およびデータ分析機構５０４を含む。
【００４４】
V. 実際ワーキング・セット（ＡＷＳ）
上述のように、本発明は、所与のベンチマーク（測定基準）に関して、動的に割当てられたメモリの実際ワーキング・セットを決定する。本発明の好ましい実施形態は、Ｕｎｉｘ環境におかれる。従って、動的に割当てられたメモリは、プロセスのヒープ(すなわち、process's heap)と呼称される。
【００４５】
ＡＷＳ決定機構５００の基本アプローチは、対象とされたプロセスがスラッシュ状態になるときどのデータ構造がページ・フォールトを引き起こすかを注意深く観察することである。この観察によって、ある１つのプロセスによって頻繁に使われるデータ構造を決定することが可能となる。図５は、本発明のＡＷＳ決定機構５００のブロック図である。図５に示されるように、本発明のＡＷＳ決定機構５００は、データ記録機構５０２およびデータ分析機構５０４を含む。ＡＷＳ決定機構５００は、Ｃプログラミング言語の文脈で特に説明されるが、いかなるプログラム言語にも適用することができる。
【００４６】
A. データ記録機構５０２
データ記録機構５０２は、データ分析機構５０４による後の分析のため、ベンチマーク実行の間のデータを記録する。図６は、本発明のデータ記録機構５０２によって実行されるデータ記録プロセスの概略流れ図を示す。図６に示されるように、データ記録プロセスは、以下のステップを含む。
【００４７】
データ記録プロセス６００は、データ記録処理の開始（ステップ６０２）から始まる。詳細は後述するが、データ記録プロセス６００は、ユーザによって起動されるベンチマーク実行の一部として起動される。
【００４８】
一旦起動されると、最初のステップで、一貫性のあるベンチマークが達成されることを確認する機能が実行される。最も正確な結果を得るため、データ記録機構５０２は、複数のベンチマークの実行を必要とし、連続したベンチマークの間、同じ動作を実行する同一セットのプロセスが首尾一貫繰り返し実行されなければならない。従って、ステップ６０４の間に、ユーザとの対話型アプローチが活用され、各ベンチマークに関するプロセスおよび関連パラメータをユーザが選択することを可能にする。ベンチマークの繰返しが多くなればなるほど、各ベンチマークの結果を比較するデータ分析機構５０４の正確性は増加する。
【００４９】
ステップ６０６において、目標プロセスに対するヒープ・ページ・フォールトの数および細分性が最大にされる。細分性とは、ページ当たりのデータ構造の数を指す。これによって、本発明は、プロセッサのページ・フォールトのメカニズムを活用して、関連データ構造がアクセスされる度数を通算することができる。ヒープ・ページ・フォールトの増加を達成する本発明の好ましい方法およびその代替方法の詳細は後述する。一旦目標プロセスが選択され、繰り返し可能なベンチマークが保証されると、ベンチマークが起動される（ステップ６０８）。
【００５０】
ステップ６１０において、時間順に配列され、タイムスタンプを記されたすべてのヒープ・ページ・フォールトを記録するリストが作成され、補助記憶装置１３８に記憶される。このリストは、データ分析機構５０４による将来の使用のため各ページ・フォールトに関するすべての関連情報を含む。
【００５１】
ステップ６１２において、時間順に配列され、タイムスタンプを記されたすべてのヒープ・トランザクションを記録するリストが作成される。本発明の好ましい実施形態のＵｎｉｘ環境において、このリストは、malloc(), calloc(), realloc()および free()に対する呼び出しなどのトランザクションを含む。このリストは、割り当てられたサイズ、割り当てられたアドレス、解放されたアドレスおよびプロシージャ呼出しトレースを含む各トランザクションについてのすべての関連情報を含む。上記ステップの各々の詳細を以下に記述する。
【００５２】
1. 首尾一貫したベンチマークの実行
ステップ６０４に関連して記述したように、すべてのメモリ調整プロジェクトの進行を客観的に測定するために、首尾一貫した、繰り返し可能なベンチマークが必要である。本発明のベンチマークは、従来型のベンチマークとは相違する。多くのベンチマークは、１つまたは２つのプロセスを扱う。一方、ステップ６０４において作成されるベンチマークは、同じプロセス間順序で同じ動作を常に実行する複数のプロセスを伴う。これは、実行毎のページ・フォールトの変化を最小にする。
【００５３】
好ましい実施例の１つでは、記録されたユーザ・セッションがベンチマークの役目を果たす。記録／再生装置１５２が、ディスプレイ装置１４８およびユーザ・インタフェース１５０におけるユーザ入力を記録する。次に、再生ツールが非常に正確にセッションを再生する。すべてのユーザ入力およびＸサーバ事象は、クライアントの動作を能動的に監視し、入力をただ受動的にＸサーバーへ送り出すことのないように、再生装置１５２で再生するのに必要な十分な時間をとらなければならない。ページ・フォールトを最大にする必要性は、要求再生環境および貧弱な記録環境に関して生じる。従って、ページ・フォールト発生が少ないときベンチマーク記録が行われ、ページ・フォールト発生が多いとき再生が行われなければならない。しかし、ベンチマーク・システムが厳しいスラッシュ状態のときセッションを厳密に再生する記録／再生機構１５２は、可能な限り迅速にセッションを再生し、ユーザ入力における間隔を圧縮し、プロセス間動作の順序を維持するように構成される。
【００５４】
2. ページ・フォールトの最大化
ページ・フォールトの数および細分性を最大にすることは、ＡＷＳ決定機構５００の正確性を増加させ、観察されたページ・フォールトに基づいてその決定が行われるようにさせる。観察されるページ・フォールトが少ない場合、データ分析機構５０４によって処理されるために生成されるデータは少ない。本発明の好ましい実施形態においては、ページ・フォールトは、データ構造のアクセスの頻度を測定するメカニズムとして使用される。記憶されるべきページ・フォールト情報を評価する現存するカーネルがあるので、ページ・フォールトが選ばれた。
【００５５】
上述の通り、１ページを占める単一のデータ構造が存在する場合最良の結果が達成されるが、多くのケースにおいては、複数のデータ構造が同一のページを占有する。そのようなページが一度だけフォールトを発生すると、ただ１つの構造だけが観察され、残りは隠れてしまう。ページのスワップ・イン、スワップ・アウトが多くなればなるほど、これらの隠れた構造を観察できる確率は高まる。例えば、頻繁にアクセスされるデータ構造の２つのタイプＡおよびＢがともにメモリ全体にわたって拡散している（すなわち局所性が小さい）と仮定する。さらに、特定のベンチマークについて、これらのデータ構造が同一セットのページを占めていると仮定する。ページ・フォールトが最大化されていないならば、ベンチマークのアクセス様態に基づいて異なるシナリオが生じる可能性がある。例えば、両タイプの構造は、その共有ページに関して、フォールトを分割するであろう。明きらかに、その２つのうちの１つがフォールトのすべてを消費する。もう一つの可能性は、もう一方の構造がフォールトのすべてを消費することである。これらのシナリオはデータ構造のタイプを隠蔽し、そのため、その発生をデータ記録機構５０２が記録することが妨げられる。
【００５６】
本発明の好ましい実施形態では、１つの構造だけが各ページを占める。これらのページが常にその使用後直ちにスワップ・アウトされるならば、これらの構造が受け取るフォールトの数は、それらが使用される頻度を示す。例えば、２つの構造ＣおよびＤを仮定し、軽度のページングの間ＣおよびＤそれぞれが１回だけのページ・フォールトを受け取り、重度のページングの間Ｃが２回のページ・フォールトを、Ｄが２０回のページ・フォールトを受け取るとする。明らかに、ＤはＣよりいっそう頻繁に使用されている。
【００５７】
いくつかのアプローチによって、ベンチマーク実行５０８の間のページ・フォールトの数および細分性を増加させることができる。最も簡単なものは、システムＲＡＭ１３６の量を減らすことである。これを実行する最も単純な方法は、システムの電源を切断し、ＳＩＭＭを取り出すことである。しかし、これは時間浪費的であり、ページ・フォールトの最適量に見合う細分性をたぶん生み出さないであろう。ページ・フォールトの最適数は、相対的に正確なＡＷＳ決定を行なうことができる程度のものではあるが、ベンチマークが受容不可能なほど長く行われるほど多数ではない。本発明の好ましいアプローチの１つは、カーネル１０８がアクセスするようにプログラムされるＲＡＭ１３６の量を、ユーザが、相対的に小さい増分値で指定することを許容する拡張カーネル１０８を使用することである。この点は、当業者の理解の範囲内にあるものとみなされる。
【００５８】
もう一つのアプローチは、メモリ管理モジュール１３４の事前ページ機能を取り外すことである。例えば、カーネル１０８は、フォールトを受けるページの周囲のページを、すぐに使用されるという予測のもと、取り込む場合がある。事前ページング機能は、通常動作の間はすぐれた機能であるが、ベンチマーク実行の間はそうではない。これは、事前ページング機能の目的がデータ構造アクセスを効果的に隠すことであるが、この点がまさに本発明のプロセスに対して相反するものであることによる。この点も当業者の理解の範囲内にあるものと考えられる。
【００５９】
本発明のもう１つの好ましい実施形態において、複数の方法が使用され、それによりデータ記録機構５０２が非常に精度の高い結果を達成する。この好ましいアプローチの第１の部分は、特定のプロセスを対象とする特別のカーネルを使用することである。すべてのプロセスの処理速度を遅くするシステムＲＡＭ減少の方法に代わって、上記特別のカーネルが、ＣＰＵメモリ管理モジュール１３４にただ１つのヒープ・ページを配置する。これを行うため、ＲＡＭにあるプロセスのページのすべてにキーを付け、ＲＡＭには単一のページしかないと信じ込ませるようにメモリ管理モジュール１３４を修正する。対象とされたプロセスは、それが異なるヒープ・ページをアクセスする度毎にフォールトを発生させる。殆どの隠れたデータ構造が見い出されるだけでなく、各データ構造使用の観察頻度も相対的に正確である。処理能力を最大にするため、カーネルは、プロセスのヒープ・ページをＲＡＭに置き、各ページ・フォールトを非常に迅速に処理するように構成される。この点も当業者の理解の範囲内にあるものと考えられる。
【００６０】
本発明の好ましいアプローチの第２の部分は、これもまた独立して利用されるものであるが、ページ・フォールトを特定のデータ構造に対応させるものである。例えば、本発明の好ましい実施形態が実施されるＵｎｉｘ環境において、２つのデータ構造が同じページを共有しないようにｍａｌｌｏｃライブラリが修正される。このようなｍａｌｌｏｃの変更は、当業者の理解の範囲内にあるものと考えられる。上述の拡張カーネルと連係して使われるとき、データ記録機構５０２の正確度はほぼ完全になる。
【００６１】
3. ページ・フォールトの記録
上述の通り、データ記録機構は，プロセスが厳しいスラッシュ状態のときページ・フォールトを観察する。各ページ・フォールトについて、データ記録機構５０２は、すべてのヒープ・ページ・フォールトについての情報を、時間順の、タイムスタンプ付きリストに記録する。図７に示すように、以下の情報が、ステップ６１０で記録される。第１に、ページ・フォールト７０２を引き起こしたアドレスが記録される。これは、ページ・フォールトが起きたときにアクセスされていたアドレスである。本発明は、データ構造を記録して、分析する。しかし、本発明がプログラム・コードに対するものであるとすれば、通算されるプログラムが記憶されるであろう。加えて、プログラム・カウンタ値７０４およびページ・フォールト７０２が記憶されるであろう。これは、ページ・フォールトを起こしたプロシージャのアドレスである。
【００６２】
好ましい実施形態において、カーネル１０８はＨＰ−ＵＸカーネルである。ＨＰ−ＵＸカーネルは、特別測定情報バッファに上述の情報を提供する。それに加えて、データ記録ツールは、既にカーネル１０８に存在していた。カーネル１０８のこの既存の記録機構に対する変更は必要であったが、これは当業者の理解の範囲内にあるものと考えられる。この記録ツールが相対的に小さく目立つものでない点に留意する必要がある。
【００６３】
4. ヒープ・トランザクションの記録
上述のように、ステップ６１０において、時間順に配列され、タイムスタンプを押されたヒープ・トランザクションのリストが作成される。上述の通り、カーネル１０８の好ましい実施形態は、Ｕｎｉｘカーネルである。ステップ６１０において、データ記録機構５０２は、Ｃプログラミング言語の動的割り当てライブラリに対する呼び出しの各々に関するすべての情報を記録する。これは、malloc(), calloc(), realloc()および free()に対する呼び出しを含む。しかし、当業者に明らかなように、本発明は、所望の高水準言語の動的割り当てライブラリに対する呼び出しを記録するように構成することができる。
【００６４】
図８に示すように、各ヒープ・トランザクションについて記録される情報は以下を含む。ヒープ・トランザクション情報は、割当て／解放状態８０２を含む。この状態は、メモリが割り当てられたか、あるいは解放されたかを示す。ヒープ・トランザクション情報は、また、割り当てられたブロックのサイズ８０４を含む。ヒープ・トランザクション情報には、また、割当て／解放アドレス８０６が含まれる。最後に、プロシージャ呼出しトレース・データ８１０が記録される。これは、各トレース行毎に以下の情報を含む。プロシージャ名８１２、あるプロシージャを別のものと区別するプロシージャの開始点からのオフセット８１４、およびプロシージャの原始ファイル８１６である。
【００６５】
第１に困難な点は、i)プロシージャ・トランザクション・トレースを迅速にかつ正確に決定すること、および ii)トランザクション別情報を迅速にかつ正確に記録する形式を設計することであった。Ｘサーバの起動（すなわちクライアントは何も実行されてない）に関する情報を記録する最初の試みは、約１７Ｍバイトを記録するのに約３０分を要した。最初の試みは、全トレースに関して全面的なＡＳＣＩＩストリングを作成する一般的ＨＰ−ＵＸトレース・ユーティリティを使用したが、それが大部分の時間と空間を占有した。
【００６６】
本発明の好ましい実施形態では、プロセッサ１４２はヒューレット・パッカードのＰＡ−ＲＩＳＣシステムであり、カーネル１０８はＨＰ−ＵＸ Ｕｎｉｘオペレーティング・システムである。ＨＰ−ＵＸに関し正確なトレースを作成することは、ＰＡ−ＲＩＳＣの共有ライブラリのため、困難である。従って、好ましい実施形態においては、アドレスのアレイを戻す特製ユーティリティが使われる。プログラムのシンボル・テーブルにあるプロシージャ名とこれらのアドレスの関連づけは、後処理まで延期された（これはベンチマーク実行の間、効果的で邪魔になるようなものではないことが判明した）。最終的な記録形式は、冗長でないバイナリ形式であった。最終的な解は、２のオーダーでメモリ空間を効率的に使用し、上記最初の試みより３のオーダーで処理時間を効率化した。
【００６７】
次に、ほとんどのプログラムが使用するmalloc()のバージョンを含んだlibc共有ライブラリを修正することが重要であった。ヒープ・トランザクション情報にタイムスタンプを押すことは、ヒープ・データをカーネル１０８に渡すことによって成し遂げられる。カーネルはデータにタイムスタンプを押し、それを上述の特別測定値インターフェース・バッファ中でページ・フォールト・データとマージする。これによって、１つのデータ記録ツールですべての情報を記録することができる。
【００６８】
B. データ分析機構５０４
データ分析機構５０４は、ベンチマークの間データ記録機構５０２によって記録された大量のデータを効率的に処理する対話型情報処理ツールである。データ分析機構５０４は、また、ユーザが、処理されたデータを対話型で活用して、プロセスのヒープＡＷＳに対する詳細な分析を行うことを可能にする。図９は、データ分析機構５０４によって実行される主プロセスの流れ図である。
【００６９】
1. ヒープトランザクションのＣデータ構造タイプへの関係づけ
上述の情報が各ヒープ・トランザクションについてデータ記録機構５０２によって記録されると、データ分析機構５０４は、ヒープ・メモリの各ブロックを特定のＣデータ構造タイプに関係づける（ステップ９０４）。詳細は後述するが、この関係づけは、記録された情報を一組の規則と比較することによって達成される。ステップ９０４の関係づけを、サンプルＸサーバにおけるサンプルのデータ構造タイプを用いて説明する。サンプルＸサーバは、装置従属型ドライバを持つワークステーション・ユーザに対するサーバのサンプルである。サンプルＸサーバは、米国マサチューセッツ州ケンブリッジ所在のX Consortium社から入手できる。
【００７０】
図１０は、ウィンドウ構造を作成するためのプロシージャ呼出しトレースを示す。サンプルＸサーバの中の最も重要なデータ構造タイプの１つは、WindowRec構造（または単にウインドウ構造）である。構造のサイズは、多数画面のＸサーバにおいて可変的であるが、単に２つの独特なプロシージャ呼出しだけがトレース・ウインドウ構造を作成するために使われる。図１０に示される通り、その２つは、ルート・ウインドウを作成するためのプロシージャ呼出しトレース１００２、およびクライアント・ウインドウを作成するためのプロシージャ呼出しトレース１００４である。しばしば、各Ｃデータ構造タイプは、本例で示されるものより単純な１つの独特な割り当てトレースだけを持つことがある点に留意する必要がある。
【００７１】
プロシージャ呼出しトレース１００２は、図１０において左側の列に示されている。ルート・ウィンドウを作成するため以下のプロシージャ呼出しが行われた。Malloc()プロシージャ呼び出し１００６は、Xalloc()プロシージャ呼出し１００８によって呼び出された。Xalloc()プロシージャ呼び出し１００８は、AllocateWindow()プロシージャ呼出し１０１０によって呼び出された。AllocateWindow()プロシージャ呼び出し１０１０は、CreateRootWindow()プロシージャ呼出し１０１２によって呼び出された。CreateRootWindow()プロシージャ呼び出し１０１２は、Main()プロシージャ呼出し１０１４によって呼び出された。
【００７２】
プロシージャ呼出しトレース１００４は、図１０において右側の列に示されている。クライアント・ウィンドウを作成するため以下のプロシージャ呼出しが行われた。Malloc()プロシージャ呼び出し１０１６は、Xalloc()プロシージャ呼出し１０１８によって呼び出された。Xalloc()プロシージャ呼び出し１０１８は、AllocateWindow()プロシージャ呼出し１０２０によって呼び出された。AllocateWindow()プロシージャ呼び出し１０２０は、CreateWindow()プロシージャ呼出し１０２２によって呼び出された。CreateWindow()プロシージャ呼び出し１０２２は、ProCreateWindow()プロシージャ呼出し１０２６によって呼び出された。ProCreateWindow()プロシージャ呼び出し１０２６は、Main()プロシージャ呼出し１０２４によって呼び出された。
【００７３】
図１０を参照して明らかなように、各トレースの中の最初の３つのプロシージャは同一である。すなわち、プロシージャ呼出し１００６、１００８および１０１０は、それぞれプロシージャ呼出し１０１６、１０１８および１０２０と同一である。これは異常ではない。実際、最初の２つと最後の２つプロシージャは、ほとんどのＸサーバ・データ構造タイプについてしばしば同一である。従って、トレースの真ん中のプロシージャに一般的に関心が払われる。この例では、AllocateWindow()が両方のトレースにある。AllocateWindow()は、Xalloc()の呼び出しを１回だけ行うので、トレースにおけるAllocateWindow()をもつヒープ・トランザクションはウインドウ構造である。
【００７４】
本発明において、Ｃデータ構造タイプを識別する好ましい方法は、1つまたは複数の規則を有する。規則は、データ構造タイプの割り当て／解放トランザクションの様相を示す仕様である。規則は、当業界でよく知られているもので、「正規表現(regular expresions)」に類似している。規則のセットには、名前（典型的には構造タイプ名）が与えられる。これらの規則が各ヒープ・トランザクションと比較される。それらは、どのトランザクションがどのＣデータ構造タイプに対応するかを決定するためにデータ分析機構５０４が使う選択基準である。ある規則があるトランザクションと一致すると、対応するヒープ・ブロックが識別される。データ分析機構５０４は、規則メモリ５０６および規則エディタ５０８を通して、このアプローチを対話型形態で実行する。
【００７５】
本発明の好ましい実施形態において使われる規則によって、各データ構造を１回以上識別することができる。データ構造タイプ名の階層を持つことが役に立つ場合がある。例えば、ピックスマップ（すなわちpixmap）が、サンプルＸサーバにおいて（例えば補助記憶、タイル、点描など）様々な目的のために使われる。従って、ある１つのセットの規則がすべてのピックスマップを識別することができ、その他のセット規則がピックスマップの特定タイプを識別することができる。
【００７６】
大量の構造タイプをもつプログラムについては、規則作成は時間浪費的である。規則作成を容易にするため、データ分析機構５０４は規則管理モジュール５０６を使用して、ユーザが規則のセットを対話型で管理することを可能にする。更に、規則エディタ５０８には、ユーザが対話型で規則を作成し編集できるダイアログが含まれる。規則作成および管理を容易にするため、規則管理モジュール５０６および規則エディタ５０８のその他の既知の機能が利用される。例えば、規則の各部分は、ワイルドカードとすることができる（ワイルドカード機能についての詳細は後述する）。これは、各規則の能力を増加させ、規則作成時間を減少させる。加えて、規則ファイルは、データ分析セッションの間規則を維持するように読み取られ書き込まれる。規則エディタ５０８を使用して数多くの方法でヒープ・トランザクションを検討することができる。例えば、ユーザは、検討するトランザクションの初期値にセットされている初期値を用いて規則エディタの使用を開始することができる。
【００７７】
図１０で示されるウインドウ構造のサンプルを使用して、各割り当てトランザクションについてのトレースには、AllocateWindow()プロシージャが含まれた。更に、AllocateWindow()プロシージャ１０１０，１０２０は、ウインドウを作成するためXalloc()１００８，１０１８に対してただ１回の呼び出しを行った。従って、ウインドウ構造を識別する明白な規則は、そのトレースがAllocateWindowという語を含むトランザクションである。トランザクションの他のいかなる部分もこの規則の中で指定されず、すべての値は、ある規則のワイルドカードとされた部分のすべてと一致するものとみなされる点注意する必要がある。
【００７８】
好ましい実施形態において、いくつかの識別されない構造が多くのページ・フォールトを引き起こす場合、メニュ選択機能が、規則エディタ・ダイアログを画面表示し、そこに構造割り当てトランザクションの値にセットされた初期値を表示する。初期規則値は、(例えばもっと一般化するため）編集し、（実際のＣデータ構造タイプ名のような）名前を与えることができる。規則が保存されるとき、すべての一致するメモリ・ブロックを識別するため、その規則はすべてのトランザクションと比較される。ユーザは、そのタイプのあらゆるデータ構造について情報を調べることができる。
【００７９】
2. 情報処理
ベンチマークが完了し、上述の情報が記録され互いに関連づけられた後、情報処理ステップが実行され、そこで、対象とされたプロセスのヒープＡＷＳのおよその決定が行われる。以下に、記録され関連づけされた情報を処理するための一般的アルゴリズムを記述する。最初に、ステップ９０６において、トランザクション・データは、データ分析に適する形式になるように処理される。ステップ９０６のトランザクション処理は、図１１を参照してさらに詳細に後述する。次に、一般にページ・フォールト処理と呼ばれる一連の機能がステップ９０８で実行される。ステップ９０８において、ページ・フォールトデータが読み込まれヒープ・トランザクション・データと関連づけらる。対応するデータ構造とページ・フォールトの間の結合が設定される。この詳細は図１２を参照して後述する。
【００８０】
a. トランザクション処理(ステップ９０６)
ヒープ・トランザクション・データに対して実行される処理を図１１を参照して説明する。最初に、ステップ１１０４において、対象とされるプロセスのシンボル・テーブルが、（ハッシュ・テーブルのような）便宜的データ構造に読み込まれる。次に、ヒープ・トランザクション・データが読み取られ処理される。
【００８１】
次に、ステップ１１０６において、各ヒープ・トランザクションは、割り当てまたは解放トランザクションとして識別される。各割り当てトランザクションの割り当てアドレスはハッシュされる。これは、割り当てそして解放するトランザクションと突き合わせるステップ９０８に関連するソフトウェアを単純化する。トランザクションの一致するセットが見つけられると、それらは交差リンクされる。
【００８２】
ステップ１１０８において、トレースの各行は、プロシージャ名、ファイル名およびプロシージャの範囲内のオフセットに変換される。トレースの各行が単にアドレスとして記録されているため、プロシージャ名は必要である。オフセットは、プロシージャの開始点からのバイト数である。トレースの各行は複数回観察されることができるので、各行はハッシュ・テーブルに入れられる。このハッシュ・テーブルは、トレース行それぞれ毎に３２ビットのキーの値を生成する。これは、データ分析機構５０４が記憶するデータをデータ分析機構が更に処理を行う（ステップ１２０６）時間を減少させる。ステップ１１０８において、各トレースは、トレース行キーのアレイとして記憶される。トレース行と同様に、各トレースもまた、ハッシュ・テーブルに入れられ、独特のトレースのため独特のキーの値が生成される。各トランザクションは、そのトレースに関しユニークなキーを記憶する。
【００８３】
b. ページ・フォールト処理（ステップ９０８）
図９を参照して述べたように、トランザクション・データが処理され、データ分析に適した形式にされた後、ページ・フォールトがステップ９０８で発生するかもしれない。図１２は、ステップ９０９でページ・フォールト処理を行う際に実行されるステップの流れ図である。図１２を参照して、本発明の好ましいページ・フォールト処理を説明する。
【００８４】
ステップ１２０４において、各解放トランザクションは、その対応する割り当てトランザクションと突き合わせられる。これは、ヒープ・ブロックが割り当てられた時間間隔を識別する。割り当てトランザクションと合致する解放トランザクションが記録されていなければ、対応するメモリ・ブロックは、潜在的なメモリ漏洩である。
【００８５】
次に、ページ・フォールトを起こしたＣデータ構造と、ページ・フォールトの各々が関連づけられる。最初に、ステップ１２０６において、データ構造タイプが、規則を使用して、関連づけられたヒープ・メモリ・ブロックと突き合わせられる。次に、ステップ１２０８において、ページ・フォールトのアドレスが、時間を越えてすべての対応するメモリ・ブロックと突き合わせられる。１つ以上の一致があれば、ステップ１２１０において、タイムスタンプの比較を行って、どのデータ構造がページ・フォールトを起こしたかを決定する。このように、ヒープ情報と各フォールトを起こしたアドレスとの比較を、特定のデータ構造と一致するまで行う。ページ・フォールト・プロセスは、ブロック１２１２で終了する。
【００８６】
例えば、特定のフォールトがベンチマーク実行の１３分で発生すると仮定する。フォールトを起こしたアドレス（Ｏｘ４ＯＯａｂ３４０)は、ヒープ・トランザクションの３つの異なるペアのアドレス範囲内にある。タイムスタンプを比較した後、どのペアがページ・フォールトに対応するかが明らかになる。この新たな相互参照情報のすべてが、ＡＷＳに関する詳細を得るために分析されることができる。
【００８７】
c. ユーザの分析
ステップ９０８でページ・フォールト処理が完了すると、データは多くの異なる形態で分析されることができる。データは、度数分布を用いて分析するため（例えばページ・フォールト数や構造のサイズで）ソートすることができる。各度数分布図の行が選択され、付加情報が要求される。局地性をを示すため、選択されたデータ構造のサイズと配置を視覚的に示す「メモリマップ」グラフを表示することもできる。
【００８８】
d. 規則の突き合わせ
規則は、作成されるかあるいは規則ファイルから読み取られるときは必ず、トランザクションと突き合わせられる。トランザクション・データベースの構造は、規則突き合わせを容易に行えるように構成される。
【００８９】
第１に、規則の各行は、トランザクション・データベースの各トレース行と比較される。一致が見つかれば、ユニークなキーが記録される（注：ワイルドカードのため、ある規則行は、複数のトレース行と一致する場合がある）。どの規則行も一致するトランザクションを見つけれない場合、規則全体がこのトランザクションと合致しないので、この規則に関する処理は停止する。
【００９０】
規則行が一致したあと、トレース規則が、トランザクション・データベースのユニークなトレースの各々と比較される。一致するトレース毎に、ユニークなキーが記録される。次に、トランザクション（複数）自体が、全体の規則と比較される（トレースの比較は、単純な３２ビットキーの整数比較である）。規則と一致トランザクションの間の交差結合が確立され、それによってデータ分析の対話型データ分析の処理能力が向上する。
【００９１】
上述の通り、本発明の好ましい実施形態において、プロセスのデータ構造が記録され分析される。しかし、当業者に明らかなように、本発明のＡＷＳ決定機構５００は、プロセスのコードや大局変数のようなプロセスのその他の特性を記録しそして分析するように構成することも可能である。
【００９２】
本発明の好ましい実施形態において、データ分析機構５０４は、ベンチマーク実行が完了し、データ記録機構が必要な情報を記憶した後その機能を実行する。しかし、当業者に明らかなように、データ分析機構５０４は、別のプロセッサに配置され、データ記録機構５０２とリアルタイムで動作することもできよう。例えば、コンピュータ・システム１００がネットワークに接続するような実施形態において、データ記録機構５０２によって記録されるデータは、ネットワークを介してコンピュータ・システム１００と通信する記憶装置に記憶されることもできる。また、コンピュータ・システム１００がネットワークに接続しているとき、データ分析機構５０４が別のコンピュータ・システムに配置され、ベンチマーク実行の完了後データ分析機能を実行することもできる。
【００９３】
上記の説明において、Ｃ言語およびＨＰ−ＵＸ Ｕｎｉｘ環境を参照して本発明を記述した。しかし、当業者に明らかなように、本発明は、Fortranのようないかなる高水準プログラミング言語に関しても動作することができる。それに加えて、本発明は、Ｗｉｎｄｏｗｓ／ＮＴ、ＶＭＳ、Ｏｐｅｎ ＶＭＳ、Ｔ／２０などいかなるオペレーティング・システムにおいても動作することができる。データ記録機構５０２およびデータ分析機構５０４を含むＡＷＳ決定機構５００は、（実行時に）主メモリ１３６に駐在しプロセッサ１４２のようなコンピュータ・システム１００のプロセッサによって実行されるコンピュータ・プログラムおよび／またはライブラリを好ましくは意味する。データ記録機構５０２によって記録されるデータは、補助記憶装置１３８に記憶することもできる。また、ＡＷＳ決定機構５００に関連するコンピュータ・プログラム／ライブラリは、フロッピーディスクまたは他の取り外し可能記憶媒体に記憶される場合もある。
【００９４】
本発明は、ハードウエア、ソフトウエアまたはそれらを組み合わせた形態のいずれでも実施することができる点理解されるべきであろう。そのような実施形態では、種々の構成要素とステップが、本発明の機能を実行するためハードウェアやソフトウェアで実施される。現存または将来開発されるコンピュータ・ソフトウェア言語およびハードウェア・コンポーネントのいずれも本発明の実施形態において使用することができる。
【００９５】
VI. 事例研究（ＡＷＳ決定機構を使用したＨＰ Ｘサーバのメモリ調整）
ＨＰ Ｘサーバのメモリ調整を行うＡＷＳ決定機構５００の実施例を以下説明する。事例研究で使用するサンプルＸサーバは、上記引用のＸ ConsortiumのＸサーバ（リリース５）である。Ｘ Consortiumのスタッフによって、本発明を使用することなく、若干の事前メモリ調整が行われた。その作業にもかかわらず、なお改善の余地があった。
【００９６】
A. ウインドウ局地性
ウィンドウ関連構造に関し３つのタイプの改善が行われた。第１に、ウィンドウ・ツリーの局地性が、汎用目的ライブラリ呼び出しのChunkAllocの使用によって改善された。第２に、ウィンドウ・プライベート構造のサイズが減らされた。最後に、Window0ptRecデータ構造の局地性が再びChunkAllocを使用して改善された。
【００９７】
前述のように、各ウィンドウ構造は個別に割り当てられる。ウィンドウ（複数）は、その階層（すなわちツリー）関係に従って互いに結合される。ウィンドウ・ツリーは、比較的頻繁に変化する。直感的に見れば、構造の相互の局地性は小さく、そのためＸサーバのＶＷＳを増加させ、不必要なページ・フォールトを発生させる。ＡＷＳ決定機構５００は、この直観を確認した。データ記録機構ベンチマークは、ウインドウ構造が（ＡＷＳにおいて）頻繁にアクセスされ、（ＶＷＳを増加させる）貧弱な局地性を持つことを明らかにした。ChunkAllocと呼ばれるライブラリを使用してウインドウをグループで割り当てるようにＸサーバが変更された。
【００９８】
B. サイズの減少
新たに改善された局地性に加えて、ＡＷＳ決定機構５００は、ウィンドウ構造がかなり大きいことを示した。これは、各ページに適合するウィンドウが相対的に少ないことを意味した。従って、各ウィンドウ・ツリーの探索に、多数のページのアクセスを要した。ＨＰ Ｘサーバは、最近その処理能力の大幅な改善が行われた。ＤＤＸコードの完全に新しい世代が開発された。しかし、新しいＤＤＸコードは、前世代からのプライベート構造をなお使用していた。それらの古いプライベート構造からはただ２、３のフィールドだけが使われ、各ウインドウについて相当のメモリが無駄に使われていた。プライベート構造の再構成の後、さらに新たにされたＤＤＸコードは、ウィンドウ当たり２００未満バイトを使用した。ChunkAllocと組み合わせたとき、ウィンドウは局地的でかつ小さくなり、従って、ページ・フォールトは少なくなった。
【００９９】
C. WindowOpt局地性
コアＸ１１プロトコルは、各ウィンドウに関する数多くの属性を指定する。Ｒ４を使用した検討の間、ほとんどのウィンドウが属性のいくつかを使用していないことが指摘された。このため、Consortiumスタッフはウィンドウ構造を分割した。彼らは、あるウインドウがあまり使用されない属性を使用する場合割り当てられる新しい構造WindowOptを作成した。ＡＷＳ決定機構５００は、（少なくとも特定のベンチマークのため）ウインドウの相当の割合がWindowOpt構造を使用することを容認した。ＡＷＳ決定機構５００は、また、主ウィンドウ構造の場合と同様に、局地性の問題を明らかにした。従って、ChunkAllocライブラリを使用して局地性を改善した。
【０１００】
D. 資源の局地性
Ｘ１１のクライアント／サーバ特性を所与とすれば、クライアントは、サーバ内部のデータ構造を直接参照しない。その代わり、クライアントは、資源識別子を使用して、それらの構造（すなわち資源）にはたらきかける。サーバは、資源識別子といくつかの内部データ構造の間の対応関係を含む資源データベースを維持する。データベースの中の各資源毎に、小さい１６バイトのデータ構造が割り当てられる。ＡＷＳ決定機構５００は、これらの小さい構造が頻繁に処理され、多くのページ・フォールトを発生させたことを明らかにした。これらの構造のメモリ・マップを参照することが明確な局地性問題を示した。再び、ChunkAllocを使用した。局地性が増加し、ページ・フォールトが減少した。
【０１０１】
E. フォント
本発明の使用により、ビットマップ・フォントを開くコードが非常に浪費的であることが明らかにされた。１つのビットマップ・フォント（ファイル）が開かれる毎に、１つの大きい構造（約８０ＫＢ）と多くの小さい構造が割り当てられ、使われ、次に解放された。各ビットマップ・フォントが開かれる時間の間に他の動作が発生したため、これらの一時的構造はヒープを断片化し、他のＡＷＳ構造の局地性を減少させた。ビットマップ・フォント・コードが実行しようとしたことを調査の結果、データ構造は偶然大きかったことが明らかになった。それは、８０ＫＢでなく２−３ＫＢあれば十分であった。小さいユーティリティ・ライブラリを作成して、比較的大きく比較的常駐するメモリの一時的構造を小さく割り当てるようにした。これによって、断片化が更に減少した。非一時的フォント構造についてこれと同じライブラリを使うことによってさらに局地性が改善された。
【０１０２】
VII. 結論
本発明が好ましい実施形態を参照して例示され説明されたが、本発明の精神と範囲を逸脱することなく、その詳細および形式を種々変更することが可能である点は当業者によって理解されるであろう。
【０１０３】
本発明には、例として次のような実施様態が含まれる。
（１）仮想メモリ・コンピュータ・システムにおいてプロセスの実際ワーキング・セットを決定するためのシステムであって、一貫性のある複数のベンチマークの実行を通して、動的に割り当てられたトランザクションおよび仮想メモリのページ・フォールトに関する情報を記録するデータ記録機構と、上記データ記録機構に接続し、動的に割り当てられたメモリのブロックの各々を特定の高水準言語データ構造に関連づけるデータ分析機構と、を備えるシステム。
（２）上記データ記録機構が、時間順に配列され、タイプスタンプを付されたページ・フォールトのリストおよび時間順に配列され、タイプスタンプを付されたページ・トランザクションのリストをコンパイルする手段を有し、上記データ分析機構が上記ページ・フォールトのリストとページ・トランザクションのリストを関係づける手段を有し、上記ページ・トランザクションを１組の規則と比較することによってページ・トランザクションがデータ構造タイプと関連づけられ、上記規則の各々が、上記データ構造タイプの１つについて、割り当てそして解放する一連のトランザクションを定義し、更に、上記データ分析機構が、割り当てトランザクションおよび解放トランザクションを識別するためのトランザクション処理手段と、上記ページ・フォールトのリストとページ・トランザクションのリストを関係づけ、ページ・フォールトと関連高水準データ構造の間の結合を形成するためのフォールト処理手段とを有する、上記（１）に記載のシステム。
（３）上記フォールト処理手段が、上記高水準データ構造に、上記フォールトの各々を発生させたコード・プロシージャを関係づける手段を含む、上記（１）に記載のシステム。
（４）仮想メモリ・コンピュータ・システムが、オペレーティング・システム・カーネルおよび物理メモリを含み、上記オペレーティング・システム・カーネルがプロセスの仮想ページの１ページだけを上記物理メモリに保持し、それによって、上記１ページの仮想ページ以外の仮想ページがアクセスされる毎にフォールトを発生させる、上記（１）に記載のシステム。
（５）上記データ分析機構が、上記１組の規則を対話型で処理する規則管理モジュールと、規則を対話型で作成し編集する規則エディタを有する、上記（１）に記載のシステム。
【０１０４】
（６）メモリ調整機能を強化するため、仮想メモリ・システムにおいて動的に割り当てられたデータ構造を持つプロセスの実際ワーキング・セットを決定する方法であって、プロセスに関し高率のページ・フォールトを誘発するステップと、当該プロセスについて反復可能なベンチマークを実行するステップと、時間順に配列され、タイプスタンプを付されたページ・フォールトのリストおよび時間順に配列され、タイプスタンプを付されたページ・トランザクションのリストのコンパイルを含むプロセス情報を記録するステップと、ヒープ・メモリのブロックを上記データ構造に関係づけるため上記プロセス情報データを分析するステップと、を含み、上記プロセス情報データを分析するステップが、各々が上記データ構造タイプの１つについて割り当てそして解放する一連のトランザクションを定義しする１組の規則と上記ページ・トランザクションを比較することによってページ・トランザクションがデータ構造タイプと関連づけられように、上記プロセス情報を関係づけるステップと、プロセスの実際ワーキング・セットを決定するため上記プロセスおよび上記関係づけられた情報を処理するステップとを含み、更に、上記プロセスおよび上記関係づけられた情報を処理する上記ステップには、割り当てトランザクションおよび解放トランザクションを識別することを含むトランザクション処理と、上記ページ・フォールトのリストとページ・トランザクションのリストを関連づけ、ヒープ・メモリの上記ブロックとデータ構造の間の結合を形成することを含むフォールト処理とが含まれる、実際ワーキング・セットを決定する方法。
（７）仮想メモリ・システムが、複数の仮想メモリ・ページを持ち、上記高率フォールトを誘発するステップが、上記仮想ページの各々に対してただ１つのデータ構造を持つことによって実行される、上記（６）の方法。
（８）仮想メモリ・システムが、オペレーティング・システム・カーネルと物理メモリを含み、上記高率フォールトを誘発するステップが、上記オペレーティング・システム・カーネルによってプロセスの仮想ページ１ページだけが上記物理メモリに保持されることによって実行され、それにより、上記１ページの仮想ページ以外の仮想ページがアクセスされる毎にフォールトが発生する、上記（６）に記載の方法。
（９）上記ページ・トランザクションのリストが、メモリのブロックが割り当てられているか、また上記ブロックが解放されているかを示すメモリ状態データ、ブロック・サイズ・データ、ブロック・アドレス・データ、タイムスタンプ、およびプロシージャ名、プロシージャ・オフセットならびにプロシージャ原始ファイル名を含むプロシージャ呼出しトレース・データを含む、上記（６）に記載の方法。
【０１０５】
（１０）上記フォールトを処理するステップが、データ構造に、上記フォールトの各々を発生させたコード・プロシージャを関係づけるステップを含む、上記（６）に記載の方法。
（１１）上記ページ・フォールトのリストが、ページ・フォールト・アドレスおよびページ・フォールト・タイムスタンプを含む、上記（６）に記載の方法。
（１２）上記プロセス情報が、プロセスの大域変数に関連するデータを含み、上記フォールト処理ステップが、上記大域変数に対するアクセスを上記ページ・フォールに関係づけるステップを含む、上記（６）に記載の方法。
（１３）上記プロセス情報が、プロセスのプログラムコード・プロシージャに関連するデータを含み、上記フォールト処理ステップが、上記プロシージャに対する呼び出しを上記ページ・フォールに関係づけるステップを含む、上記（６）に記載の方法。
（１４）上記プロセス情報が、プロセスの静的に割り当てられたオブジェクトに関連するデータを含み、上記フォールト処理ステップが、上記オブジェクトに対するアクセスを上記ページ・フォールに関係づけるステップを含む、上記（６）に記載の方法。
（１５）上記トランザクションを処理するステップが、ハッシュ・テーブルにプロセスのシンボル・テーブルを読み込むことを含む、上記（６）に記載の方法。
（１６）上記フォールト処理ステップで結合されたデータを画面表示するステップを含む、上記（６）に記載の方法。
（１７）上記フォールト処理ステップが、上記割り当てトランザクションの各々を上記解放トランザクションの１つと突き合わせるステップと、上記ページ・フォールトの各々をデータ構造の１つに関係づけるステップとを含む、上記（６）に記載の方法。
（１８）上記フォールト処理ステップが、上記解放トランザクションの１つが上記割り当てトランザクションの１つと合致しない場合、潜在的メモリ漏洩を示すステップを含む。上記（６）に記載の方法。
【０１０６】
【発明の効果】
本発明のＡＷＳ決定機構によって、プロセスに動的に割り当てられるメモリ・ワーキング・セットについて、実際に頻繁に使用される部分を特定することが可能となり、その分析結果を活用してプロセスのメモリ調整を行うことによって、マルチタスク仮想メモリ環境におけるシステム処理能力の向上を図ることができる。
【図面の簡単な説明】
【図１】本発明が実施される好ましいコンピュータ環境を示すブロック図である。
【図２】物理メモリと仮想メモリの間の関係を示すブロック図である。
【図３】システムＲＡＭおよび補助メモリに仮想メモリが記憶される形態をとる仮想メモリ・システムの例を示す図である。
【図４】プロセスの仮想ワーキング・セット（ＶＷＳ）および実際ワーキング・セット（ＡＷＳ）を示すブロック図である。
【図５】本発明の実際ワーキング・セット決定機構の処理ステップを示すブロック図である。
【図６】本発明ののデータ記録機構によって実行されるデータ記録プロセスの流れ図である。
【図７】典型的なベンチマーク実行の間記録されるページ・フォールト・データのテーブルを示す図である。
【図８】典型的なベンチマーク実行の間記録されるヒープ・トランザクション・データのテーブルを示す図である。
【図９】本発明のデータ分析機構によって実行されるデータ分析プロセスの概要を示す流れ図である。
【図１０】ウィンドウ構造を作成するためのプロシージャ呼出しトレースのテーブルを示す図である。
【図１１】本発明のデータ分析機構によって実行されるトランザクション処理の流れ図である。
【図１２】本発明のデータ分析機構によって実行されるページ・フォールト処理の流れ図である。
【符号の説明】
１００ コンピュータ・システム
１０６ ユーザ・アプリケーション・レベル
１０８ カーネル・レベル
１１０ ハードウエア・レベル
１３６ 主メモリ
１３８ 補助メモリ、または補助記憶装置
２０２ 物理メモリ
２０４ 仮想メモリ
２０６ スワップ空間
２１０、４０２ ページ
４０４ 仮想メモリ・ワーキング・セット（ＶＷＳ）
４０６ 実際ワーキング・セット（ＡＷＳ）
【発明の属する技術分野】
本発明は、一般的にはマルチタスク環境における仮想メモリの管理に関するもので、特に、プロセスのワーキング・セットに必要なＲＡＭを減少させるシステムおよび方法に関するものである。
【０００２】
【従来の技術】
長年にわたってシステムＲＡＭの要求量は指数的に増大してきた。例えば、初期のＰＤＰ−１１ミニコンピュータは、わずか６４ＫＢ(キロ・バイト)のＲＡＭでＵｎｉｘを実行した。初期のワークステーションの中には、ハードウエア上最大２ＭＢ（メガ・バイト）に限定されるものもあった。今日では、最新のデスクトップ・ソフトウェアを実行させるとき、１６ＭＢをもつエントリ・レベルのワークステーションでさえ遅く見えることがある。
【０００３】
従来行われてきたメモリ対策の１つは、メモリ使用調整を不要のものとして退け、ＲＡＭを単に増設するというものである。結局、ＲＡＭ価格は下落し続けるが、システム価格もまた下落し続ける。ＲＡＭの必要性の相対的比率の増大を所与とすれば、ＲＡＭ価格が減少し、システム価格が減少しても、ＲＡＭはシステム費用の主要部分を占めることに変わりはない。加えて、今日の競争環境において、あるソフトウェアが一層多くのＲＡＭを必要とし、その結果、他のソフトウエアより高価なシステムを必要とすれば、そのソフトウエアの営業担当者はその販売に苦労することとなる。
【０００４】
従来技術の解決策は、主として仮想メモリのページング・アルゴリズムを改善することに焦点を集めてきた。その例のいくつかを、Gupta、Franklin両氏著の IEEE, Transactions on Computers C-27-706-712 (1978)、Levy、Lipman両氏著のComputer 15:35-41 (1982)および Loreti、Deitel両氏著のOperating Systems, Addison-Wesley, Reading, MA (1981)で参照することができる。これらの従来技術の改良は、大きいプログラムを一層効率的に実行させることを可能にしている点において重要ではあるが、それらはメモリ使用の継続的増加を考慮に入れてない。従って、最も先進的ページング・アルゴリズムをもってしても、プロセスが増大し続けるにつれ、システムＲＡＭ要求は増加し続ける。
【０００５】
【発明が解決しようとする課題】
しかしながら、ＲＡＭを増設しても、この追加ＲＡＭの多くが付加機能によって消費される一方で、その多くが貧弱なプログラミング実施の結果としてただ浪費されている。種々の技術を使用して、浪費されたＲＡＭの返還をめざしメモリ調整の努力が払われたが、明確な成功は得られてない。この不成功は、従来技術のシステムにおけるメモリ調整機構が、特定のプロセスのワーキング・セットの構成内容に関し十分な洞察を行う能力に欠けていることによる。従って、ある１つのプロセスによって頻繁に利用されるＲＡＭの量を減少させることによって浪費されるＲＡＭの回収をメモリ調整機構が可能にするシステムが必要とされている。
【０００６】
【課題を解決するための手段】
本発明によって、プロセスのデータ構造利用度に関する情報を提供する対話型情報記録および処理ツールが提供される。この情報は、プロセスの動的に割当てられるメモリのワーキング・セット（すなわちメモリ上の作業領域）を減少させるために使われる。本発明が提供する「実際ワーキング・セット」（Actual Working Setの頭文字をとって以下ＡＷＳと呼称する場合もある）決定機構は、システムを改良するアプローチでなく、所与のプロセスが効率的に動作するようにプロセス自体を改善するために必要な情報をメモリ調整機構に与えることによって仮想メモリ問題へ対処するというアプローチをとる。
【０００７】
本発明は、どの部分が頻繁に使用されるか、すなわち、プロセスの仮想メモリ（Virtual Memoryの頭文字をとって以下ＶＭと呼称する場合もある）のワーキング・セット（仮想メモリ・ワーキング・セットVirtual Memory Woroking Setをその頭文字をとって以下ＶＷＳと呼称する場合もある）と呼ばれる動的に割当てられるページが実際にどれほど使われるかを決定する。プロセスが頻繁に使用する実際のメモリは、プロセスの実際ワーキング・セット（ＡＷＳ）と呼ばれる。
【０００８】
本発明は、所与のベンチマークを実行して、動的に割当てられるメモリの実際ワーキング・セットを決定する。ＡＷＳ決定機構の基本的アプローチは、対象とされるプロセスが厳しいスラッシュ状態（すなわち、頻繁なページ・フォールトのためプロセスの実行が極度に停滞する状態）のとき、どのデータ構造がページ・フォールトをひき起こすかを観察することである。本発明には、データ記録機構およびデータ分析機構が含まれる。データ記録機構は、最も正確な結果が得られるように一貫したベンチマークが行われることを保証し、目標プロセスに関するヒープ・ページ・フォールトの数と細分性を増加させてプロセッサのページ・フォールト・メカニズムが関連データ構造のアクセス回数を通算することを可能にし、すべてのヒープ・ページ・フォールトおよびトランザクションを記録する。
【０００９】
データ分析機構は、ベンチマーク実行の間データ記録機構によって記録された大量のデータを効率的に処理する対話型情報処理ツールである。データ分析機構は、また、ユーザが処理されたデータを対話モードで活用し、プロセスのヒープＡＷＳを精密に分析することを可能にする。データ分析機構は、ヒープ・メモリの各ブロックを特定のＣ言語データ構造に関係づける。ベンチマークが完了し、上述の情報が記録され、関係づけられた後、該情報の処理ステップが実行され、対象とされたプロセスのヒープＡＷＳが決定される。
【００１０】
【発明の実施の形態】
Ｉ. はじめに
本発明は、プロセスのデータ構造の活用度に関する情報を提供する対話型記録ツールおよび処理ツールを提供する。この情報は、動的に割当てられるプロセスのメモリのワーキング・セットを減少させるために使われる。本発明の実施形態について、以下、システム概要、仮想メモリおよびワーキング・セット理論の簡単な考察、動的割当てプロセスのメモリの実際ワーキング・セットの認定、最後に、事例研究の順に説明する。
【００１１】
II. システムの概要
図１は、本発明の好ましい実施形態であるコンピュータ・システム１００を示すブロック図である。図１は、ＵＮＩＸシステム・カーネルであり、種々のモジュールとその相互関係を示す。特に、図１は、ＵＮＩＸシステム・カーネル１０８の２つの主要コンポーネントである、ファイル・サブシステム１０２およびプロセス制御サブシステム１０４を示す。いくつかのモジュールが他のモジュールの内部動作と相互に作用するので実際のカーネルはモデルと異なるが、図１は、ＵＮＩＸシステムの論理的側面を観察するのに役立つ。
【００１２】
図１は、コンピュータ・システム１００の３つのレベル、すなわち，ユーザ・レベル１０６、カーネル・レベル１０８およびハードウェア・レベル１１０を示す。システム呼び出しインターフェース１１２およびライブラリ・インターフェース１１４は、アプリケーション・プログラム１１６とカーネル１０８の間の境界を表す。システム呼び出しは、Ｃプログラムにおける通常の関数呼び出しと同様であり、ライブラリはオペレーティング・システムに入るために必要とされるプリミティブへこれらの関数呼出しを対応づける。しかし、アセンブリ言語プログラムが、システム呼び出しライブラリなしで直接システム呼び出しを起動するために使われることもある。プログラムは、しばしば標準入出力ライブラリのような他のライブラリを使用してシステム呼び出しの一層高度な使用を行う。ライブラリは、コンパイル時にプログラムにリンクされ、アプリケーション・プログラムの一部となる。
【００１３】
図１では、システム呼び出しのセットは、ファイル・サブシステム１０２と対話するものとプロセス制御サブシステム１０４と対話するものに区分されている。ファイル・サブシステム１０２は、ファイルを管理し、ファイル空間を割り当て、空き空間を管理し、ファイルへのアクセスを制御し、ユーザに代わってデータを取り出す。プロセスは、従来技術において既知のシステム呼び出しの特定のセットを介してファイル・サブシステム１０２と対話する。
【００１４】
ファイル・サブシステム１０２は、カーネル・レベル１０８と補助メモリとして図示されている補助記憶装置１３８との間のデータの流れを制御するバッファ・キャッシュ１１８を使用して、ファイル・データにアクセスする。バッファ・キャッシュ１１８は、ブロックＩ／Ｏデバイス・ドライバ１２４と対話して、カーネル１０８との間でのデータ転送を始動させる。デバイス・ドライバは、周辺装置の動作を制御するカーネル・モジュールである。ブロックＩ／０装置１２４は、ランダム・アクセス記憶装置であるか、または、そうでない場合、デバイス・ドライバによって、システム１００の残りの装置にとってランダム・アクセス記憶装置であるように見えるようにされる。例えば、テープ駆動装置は、カーネル１０８がランダム・アクセス記憶装置としてテープ装置を読み取ることを可能にする。ファイル・サブシステム１０２は、また、バッファ・キャッシュ１１８の干渉なしに「生の」Ｉ／０デバイス・ドライバと直接対話する。生のデバイスは、しばしば文字デバイス・ドライバ１２２と呼ばれ、ブロック・デバイス・ドライバ１２４以外のすべてのデバイスを含む。ほとんどのブロック装置１２４は、また、文字デバイス・インターフェースを提供し、カーネル１０８をバッファ・キャッシュ１１８へバイパスさせることを可能にする。これは、ブロック装置への「生のＩ／０」と呼ばれる。文字デバイス１２２とブロックＩ／Ｏ装置１２４を合わせたものがデバイス・ドライバ１２０を構成する。
【００１５】
プロセス制御サブシステム１０４は、プロセス間通信１３０、メモリ管理１３４、およびプロセス同期／スケジューリング１３２に対して責任を持つ。ファイル・サブシステム１０２およびプロセス制御サブシステム１０４は、実行のためメモリにファイルをロードするとき、相互に対話し、プロセス制御サブシステム１０４は、実行する前にメモリに実行可能ファイルを読み込む。プロセス制御サブシステム１０４は、プロセスを制御するため既知のシステム呼び出しを実行する。
【００１６】
メモリ管理モジュール１３４は、メモリの割り当てを制御する。システムがすべてのプロセスのために十分な物理メモリを有していないならば、カーネル１０８は、すべてのプロセスが公正な機会を得るように、主メモリ１３６と補助メモリ１３８の間でそれらプロセスを移動させる。一般的に、メモリを管理するため、スワップと要求ページングという２つの方策がある。スワップ・プロセスは、プロセスに対するメモリの割り当てを「スケジュール」して、ＣＰＵスケジューラの動作に影響を及ぼすので、スケジューラ１３２と呼ばれることがある。
【００１７】
スケジューラ・モジュール１３２は、ＣＰＵをプロセスに割り当てる。スケジューラ・モジュール１３２は、資源を待つ間プロセスが自発的にＣＰＵを放棄するまで、または、プロセスの最近の実行時間がある時間量を越える時カーネルがプロセスに対し優先実行を開始するまで、プロセスを順番に実行させるようにスケジュールする。次に、スケジューラ１３２は、実行させる最優先順位を持つプロセスを選択する。元のプロセスが、実行可能な最優先順位を持つプロセスである場合再び実行する。プロセス間通信１３０には、事象の非同期信号からプロセス間の同期メッセージ伝送におよぶいくつかの形態がある。
【００１８】
最後に、ハードウェア制御１４０は、割込みを処理し、ハードウェア・レベルと通信する機能を果たす。ハードウェア・レベル１１０は、プロセッサ１４２、システム・メモリまたは主メモリ１３６およびシステム・バス１４４を備える。主メモリ１３６は、好ましくは、ランダム・アクセス・メモリ（すなわちＲＡＭ）である。プロセッサ１４２の適切な形態の１つは、既知のＩＢＭ社製ＲＩＳＣＳｙｓｔｅｍ／６０００コンピュータ・ファミリである。好ましくは、プロセッサ１４２は、ヒューレット・パッカード社ＰＡ‐ＲＩＳＣＳｙｓｔｅｍである。しかしながら、本発明の範囲と精神を逸脱することなく、その他のコンピュータを代替的に使用することは可能である。
【００１９】
ハードウェア・レベル１１０には、Ｉ／Ｏバス１４６に接続した、補助記憶装置１３８、ディスプレイ装置１４８、およびキーボードまたはマウス等のユーザ・インタフェース装置１５０を含む数多くの周辺装置がさらに含まれる。補助記憶装置１３８は、例えば、ハードディスク・ドライブやフロッピーディスク・ドライブを含む。加えて、ユーザ・インタフェース１５０へのユーザ入力を記録し、ディスプレイ装置１４８に表示し、次に、Ｉ／Ｏバス１４６を経由して直接再生するため記録／再生装置１５２が使われる。プロセスの実行中に、ディスクまたはターミナルのような装置は、ＣＰＵへの割り込みを行うかもしれない。そのような場合、カーネルは割り込みを処理した後割り込まれたプロセスの実行を再開する。割り込みは、専用プロセスによって処理されることはなく、現在実行中のプロセスの範囲に呼び出されているカーネルの特殊機能によって処理される。
【００２０】
カーネル１０８の適切な形態は、米国ニュージャージー州マレイ・ヒル所在のAT&T Bell Laboratoriesによって開発されたAT&T Unix System V、および米国カリフォルニア州バークレイ所在のカリフォルニア大学バークレイ校によって開発されたBerkeley Software Distribution (BSD) Unix systemなどのような既知の、一般に使用されているＵｎｉｘシステムである。特定のアプリケーションまたは機械のために構成されたこれらＵｎｉｘシステムのバリエーションも使用可能である。そのような構成には、米国コロラド州フォート・コリンズ所在のヒューレット・パッカード社が開発した、本発明の好ましい実施形態であるＨＰ‐ＵＸＵｎｉｘオペレーティング・システムが含まれる。
【００２１】
III. 仮想記憶装置と従来のワーキング・セット・モデル
コンピュータ・システム１００は、仮想メモリ・システムである。図２は、物理的メモリと仮想メモリの間の関係を図示する。図２では、主メモリ１３６における物理メモリは、物理的ページ２０２として図示されている。仮想メモリ（ＶＭ）システムは、主メモリ１３６が実際より大きい数の物理的ページ２０２を保持する容量を持つかのような錯覚をコンピュータ・プロセスに与える。従って、コンピュータ・システム１００において動作するあらゆるプロセスは、システムに実装された主メモリ１３６の物理的メモリ（ＲＡＭ）量１３６より非常に大きい仮想アドレス空間２０４を持つことができる。ＶＭシステムは、複雑な形態でこの錯覚を与える。
【００２２】
仮想および物理両アドレス空間は、ページと呼ばれる小さい構成要素２０６に分割される。ページ２０６のサイズは、典型的には、２−３ＫＢである。各ページは、実際には、ＲＡＭ（主メモリ１３６）または補助記憶装置１３８のようなスワップ空間２０６に置かれる。メモリ・マネージャ１３４は、各仮想ページ２０８とその実際の位置の間のマッピング（すなわち対応関係）を維持する。このマッピングの一部は、ＣＰＵ１４２内の特別なメモリ管理ハードウェアに記憶される。各仮想メモリのアクセスは、このメモリ管理ハードウェアを経由する。メモリ位置のページがＲＡＭ１３６に位置づけられていれば、物理的メモリ２０２の正確な物理アドレスが、メモリ・アクセスのために使われる。仮想メモリ位置のページがスワップ空間２０６に位置するならば、メモリ・アクセスが起きる前に、ページをＲＡＭ１３６にロードするためページ・フォールトが発生する。
【００２３】
ＲＡＭ１３６がいっぱいのときは、あるページがＲＡＭに呼び込まれる前に別のページがスワップ空間２０６に送り出されなければならない。現在メモリにあるページが「ページ・アウト」または「スワップ・アウト」される。メモリ管理モジュール１３４は、スワップ・アウトすべきページ２１０を公平な方法で決定するようにつとめる。一般的に、上述のページ活動を実行する時間は、プロセッサ１４２の処理速度に比較して長い。正確な時間は、スワップ・ディスクとコンピュータの相対的速度のような種々の因子に依存するが、ページ処理の時間が長いため、あるプロセスがページ・フォールトに遭遇すると当該ページのＲＡＭ１３６への書き込みが終了するまでそのプロセスは中断される。
【００２４】
例えば、コンピュータ・システム１００が６４ＫＢの物理メモリ２０２のＲＡＭ１３６を持ち、各ページのサイズが４ＫＢであるとすると、システムは１６個のページからなる物理メモリ２０２を持つこととなる。あるプロセスが１２８ＫＢの仮想メモリを利用する場合、それは３２個のページからなる仮想メモリを持つ。プロセスが１７番目のページの中のアドレスをアクセスしようとする時点でプロセスの最初の１６個のページがＲＡＭ１３６にロードされているとすれば、メモリ管理モジュール１３４は、１７番目のページのアクセスに関してページ・フォールトを発生させる。スワップ空間２０６から１７番目のページをページ・インさせるため、ＲＡＭ１３６にある最初の１６個のページの１つがスワップ空間２０６へスワップ・アウトされなければならない。
【００２５】
プロセスが同一の１６個のページ内に大部分のメモリ・アクセスを保持していれば、ページ・フォールトはほとんど発生せず、従って処理速度はすぐれている。しかし、プロセスがラウンドロビン方式（すなわち巡回方式）で３２個のページすべてをアクセスするならば、それは殆どの時間中断される。このような事態が発生すると、プロセスはスラッシュ(thrash)状態であるといわれる。殆どの活動的プロセスが過剰なページングに遭遇すると、システムはスラッシュ状態であるといわれる。「活動的」プロセスがほとんどの時間中断されるので、ほどんど進展は見られない。
【００２６】
好ましい実施形態のＨＰ−ＵＸオペレーティング・システムのような最近のマルチタスク・オペレーティング・システムは複雑な仮想メモリ管理システムを使用する。第１に、カーネルは、いくつかのプロセスを同時にタイム・スライスすることを試みるので、コンピュータのＲＡＭのすべてを１つのプロセスに割り当てることはない。ＲＡＭは、複数のプロセスに使われる仮想ページを含む。第２に、最近のカーネルは、ページ・フォールトの数を減らすため高度のアルゴリズムを使う。例えば、ＨＰ−ＵＸカーネルは、特定のページ・フォールトが発生すると、直後にアクセスされる場合に備えて周辺のページを同時にページ・インすべきか否かを判断する。カーネルは、また、スワップすべきページ（例えば再度すぐに呼び込まれる可能性のないページ）を決定するため種々の基準を保持する。カーネルは、プロセスのワーキング・セットに使われているメモリをけっしてページ・アウトしない。
【００２７】
P. J. Denning氏によって"Communications of the ACM 11:323-333 (1968)"および"IEEE Transactions on Software Engineering SE-6:64-84 (1980)"で紹介されているワーキング・セット・モデルは、マルチ・オペレーティング・システムにおけるＶＭ動作を理解するのに役立つ。ワーキング・セット・モデルを支持する基本的概念は、プロセスがその（複数）ページのサブセットを頻繁にアクセスすることである。これらのページは、プロセスのワーキング・セット（すなわち実働セット）と呼ばれる。ワーキング・セットのページは、プロセスがスラッシュ状態にならないようにメモリに常駐したままでいなければならない。
【００２８】
ある１つのプロセスのワーキング・セットは、時間の経過とともに変化する傾向がある。例えば、起動時におけるプロセスのワーキング・セットは、安定状態のワーキング・セットより非常に大きくまた非常に異なっていることがある。また、メニュ選択型プログラムのワーキング・セットは、ユーザが異なるメニュ項目を選択するにつれて変化する可能性がある。
【００２９】
すべてのプロセスの仮想メモリのサイズが使用可能ＲＡＭの範囲内でまかなえる場合は、プロセスが最初のページをアクセスするときにのみページ・フォールトは発生する。そのような場合ではシステム処理能力はスラッシュに苦しむことはない。スラッシシュ状態は、すべての活動プロセスのワーキング・セットの総和が使用可能ＲＡＭを越えるとき発生する。そのような状況では、１つのプロセスのワーキング・セットのページ・インを行うために、別のプロセスのワーキング・セットがページ・アウトされなければならない。
【００３０】
プロセスがスラッシュ状態であることをカーネルが検出すると、カーネルは劇的対応策を開始する。例えば、カーネルは全体のプロセスをスワップ・アウトして残りの１つまたは複数のプロセスのために使用可能なページの数を増加させることがある。当然のことながら、スワップ・アウトされたプロセスが最後に再び実行される場合、それらのワーキング・セットのページのすべては呼び込まれなければならず、そのためその他のプロセスはスワップ・アウトされる。上述のように、システム処理能力を向上させスラッシシュの発生確率とその悪影響を減少させるため、ＶＭページング・アルゴリズムに対し種々の改善が提案されてきた。しかしながら、上述のように、これらの改善は、メモリ使用の継続的な増加を考慮に入れていない。
【００３１】
IV. 実際ワーキング・セット（ＡＷＳ）の決定
Ａ．本発明のワーキング・セット・モデル
上記説明において、「ワーキング・セット」という用語は、特に仮想メモリ・システム・ページ２０４を指すものとして使われた。これは、伝統的に仮想メモリの改善に焦点が当てられてきたことによる。伝統的改善は、メモリ管理モジュール１３４によって実行されるページング機能に集中している。これは、おそらく、常駐プロセスがオペレーティング・システムの作成者以外の製造業者によって作成されることによる。しかし、本発明のシステムおよび方法は、メモリ管理モジュール１３４を改善するというよりもむしろプロセス自体を改善し、それによって所与のプロセスが一層効率的に動作することを意図する。この異なる見解とアプローチを実現するため、当業界において使われる伝統的な定義を検討しなければならない。
【００３２】
図３を参照すれば、非ワーキング・セット・メモリを調整してもシステム処理能力は改善されないことは十分理解されるであろう。例えば、上記で説明した例および図３を参照して、プロセスのサイズ全体は３２個のページのままで、ワーキング・セットが１７個のページ（例えば、ページ１−１７）であると仮定し、システム・メモリ１３６はなお１６個のページだけを備えているとすれば、従来技術のワーキング・セット・モデルに従えば、コンピュータ・システム１００はスラッシュする。ワーキング・セットにない８個のページ（例えばページ２５ないし３２）を追い出すというメモリ調整努力は、なお、システム１００をスラッシュさせる。これは、排除されるページのいずれもワーキング・セットにないためである。このように、プロセスの１／４がページ・アウトされても、システム１００はなおスラッシュする。その代わり、ワーキング・セット・ページの１つ（例えばページ１７）がワーキング・セットから除かれれば、コンピュータはもはやスラッシュしない。
【００３３】
本発明に従うプロセスのワーキング・セットの定義を図４を参照しながらここで説明する。メモリ管理モジュール１３４の観点からすれば、全体ページ４０２が、そのプロセスのワーキング・セットであるが、プログラムはそのページの一部を使用しているだけかもしれない。従って、本発明においては、頻繁に使用され、または動的に割当てられるページを、プロセスの仮想メモリ（ＶＭ）ワーキング・セット（ＶＷＳ、Virtual Working Set）と呼ぶ。プロセスが頻繁に使用する実際のメモリをプロセスの実際ワーキング・セット（Actual Working Setの頭文字をとって以下ＡＷＳと呼称する場合もある）４０６と呼ぶ。典型的にはメモリ調整はＣおよびFortranのような高級言語を利用して実行されるので、ＡＷＳ４０６は、プロシージャおよびデータ構造を用いて表現される。ＶＷＳ（伝統的なワーキング・セット）４０４はページとして表現される。すなわち、データ構造またはコードは、特定ページの小さい部分４０６を利用する。
【００３４】
ほとんどの状況において、ＡＷＳ４０６は、ＶＷＳ４０４より常に小さい。これは、細分性が相違しているからである。ＡＷＳ４０６の細分性は、バイト単位で測られ、一方ＶＷＳ４０４は、各ページのサイズ（典型的には２、３ＫＢ）で常に測られる。本発明は、サイズにおけるこの相違を活用して、仮想メモリ・ワーキング・セット４０４のどの部分が実際ワーキング・セット４０６に含まれるかを決定する。
【００３５】
図３に関連した上述の例を参照して、ＶＷＳ４０４は１７ページであって、そのうちプログラム・コードが１ページ（例えば最初のページ）を占め、プログラムは２つのセットの変数に常時アクセスすると仮定する。さらに、第１の変数セットは２番目のページの約１／２を占め、第２の変数セットは、１６個のエレメントからなる結合リストであると仮定する。なお、上記リストにおいて、各エレメントのサイズは２４バイトであり、エレメントのそれぞれは、上記第２のページの後半から始まって別のページに記録されていると仮定する。
【００３６】
この特定のケースにおいて、本発明は、ＡＷＳ４０６として実際に使われるＶＷＳ４０４の部分だけを考慮する。この例において頻繁にアクセスされる特定のデータ構造は相対的に非常に小さい。ＡＷＳ４０４もそれに応じて小さい。この情報によって、プログラマは結合リストが２番目のページ内にだけ収納されるようにプログラムを慎重に設計することができるであろう。そのようなケースでは、ＶＷＳ４０４は、１７ページではなくわずか２ページとなる。これはＡＷＳ４０６のサイズに一層近くなる。
【００３７】
Ｂ．本発明の好ましいメモリ調整
メモリ調整は、当該プロセスのＶＷＳを減少させるプロセスであるとみなされる。スラッシュの原因となるプロセスに対してメモリ調整が行われれば、スラッシュは減じられるか、除去される。典型的には、メモリ調整は、以下のタイプのタスクの１つまたは複数を実行するものとして一般的に説明される。すなわち、(1)局地性の改善、(2)ヒープ断片化の減少 、(3)メモリ漏洩の除去、(4)コードおよびデータ構造のサイズの減少、(5)メモリの再使用、および(6)ワーキング・セット増大のスケジュール化、である。
【００３８】
局地性の改善に関しては、相対的に小さく、かつ異なるページにまたがって存在する項目への頻繁なアクセスは、ＶＷＳを（上述のように）不必要に増大させる。可能な限り項目を隣接して割り当てることによって、（サイズ的にＡＷＳへ近似した）より小さいＶＷＳとなり、ページ・フォールトの発生が少なくなる。この規則は、データにもコードにもあてはまる。例えば、頻繁に使われるプロシージャをグループ化すれば、コードのＡＷＳを減らすことができる。（ＨＰ−ＵＸと連係するコンパイラなど）コンパイラによっては、コードに関してこの作業を自動的に行う。
【００３９】
ヒープ断片化は、未使用の穴を累積して放置する形態でメモリを割り当て解放する場合に発生する。断片化はＡＷＳの局地性を減らし、そのため不必要にＶＷＳを増大させる。メモリ漏洩は、割当てられたメモリがもはや使われないのにかかわらず解放されない場合に発生する。メモリ漏洩も、ＡＷＳの局地性を減らし、そのため不必要にＶＷＳを増大させる。
【００４０】
コードおよびデータ構造のサイズを減らす目的は、ＡＷＳおよびＶＷＳを縮小することである。例えば、ある構造が、いくつかのブーリアン値の各々に関し複数の３２ビット・フィールドを含むとすれば、その代わりに、１ビットのフィールドからなるグループを使用することができる。１６ビット整数フィールドを３２ビット整数の代わりにあてることができる場合が多い。使用頻度の少ないコード／データを頻繁に使われるコード／データの中から引き出すことができる場合が多い（例えば、ＸサーバのＷｉｎｄｏｗＯｐｔＲｅｃ）。
【００４１】
メモリの再使用は、システム処理能力を向上させる。例えば、プロシージャが起動される毎に、１つまたは複数の一時的項目を割り当て、使用し、次に、解放すると仮定する。一旦項目を割り当て、将来の使用に備えて周囲に保持することによって、ヒープ断片化は減少する（このため他のヒープ・データ構造に対する局地性を改善することができる）。
【００４２】
ワーキング・セット増大のスケジュール化は、また、システム処理能力を向上させる。例えば、プロセスのＶＷＳは、起動時に大きいことが多い。同時にいくつかのプロセスを起動させることは、一時的なスラッシング状態の誘因となる。プロセスの起動を同期化させることによって、ワーキング・セットの大きさの総和がスラッシュを引き起こす程の大きさにはならないであろう。これはシステム・レベルの例ではあるが、同様の例をコードについても観察することができる。
【００４３】
上述の諸改善を効果的に成し遂げるため、本発明は、プロセスのプログラムの開発に用いたものと同じ高級言語プロシージャおよびデータ構造で表される当該プロセスのＡＷＳを決定する。上述のように、本発明は、データ記録およびデータ分析機構を実行する。図５は、本発明の好ましい実施形態のブロック図である。図５に示されるように、本発明のＡＷＳ決定機構５００は、データ記録機構５０２およびデータ分析機構５０４を含む。
【００４４】
V. 実際ワーキング・セット（ＡＷＳ）
上述のように、本発明は、所与のベンチマーク（測定基準）に関して、動的に割当てられたメモリの実際ワーキング・セットを決定する。本発明の好ましい実施形態は、Ｕｎｉｘ環境におかれる。従って、動的に割当てられたメモリは、プロセスのヒープ(すなわち、process's heap)と呼称される。
【００４５】
ＡＷＳ決定機構５００の基本アプローチは、対象とされたプロセスがスラッシュ状態になるときどのデータ構造がページ・フォールトを引き起こすかを注意深く観察することである。この観察によって、ある１つのプロセスによって頻繁に使われるデータ構造を決定することが可能となる。図５は、本発明のＡＷＳ決定機構５００のブロック図である。図５に示されるように、本発明のＡＷＳ決定機構５００は、データ記録機構５０２およびデータ分析機構５０４を含む。ＡＷＳ決定機構５００は、Ｃプログラミング言語の文脈で特に説明されるが、いかなるプログラム言語にも適用することができる。
【００４６】
A. データ記録機構５０２
データ記録機構５０２は、データ分析機構５０４による後の分析のため、ベンチマーク実行の間のデータを記録する。図６は、本発明のデータ記録機構５０２によって実行されるデータ記録プロセスの概略流れ図を示す。図６に示されるように、データ記録プロセスは、以下のステップを含む。
【００４７】
データ記録プロセス６００は、データ記録処理の開始（ステップ６０２）から始まる。詳細は後述するが、データ記録プロセス６００は、ユーザによって起動されるベンチマーク実行の一部として起動される。
【００４８】
一旦起動されると、最初のステップで、一貫性のあるベンチマークが達成されることを確認する機能が実行される。最も正確な結果を得るため、データ記録機構５０２は、複数のベンチマークの実行を必要とし、連続したベンチマークの間、同じ動作を実行する同一セットのプロセスが首尾一貫繰り返し実行されなければならない。従って、ステップ６０４の間に、ユーザとの対話型アプローチが活用され、各ベンチマークに関するプロセスおよび関連パラメータをユーザが選択することを可能にする。ベンチマークの繰返しが多くなればなるほど、各ベンチマークの結果を比較するデータ分析機構５０４の正確性は増加する。
【００４９】
ステップ６０６において、目標プロセスに対するヒープ・ページ・フォールトの数および細分性が最大にされる。細分性とは、ページ当たりのデータ構造の数を指す。これによって、本発明は、プロセッサのページ・フォールトのメカニズムを活用して、関連データ構造がアクセスされる度数を通算することができる。ヒープ・ページ・フォールトの増加を達成する本発明の好ましい方法およびその代替方法の詳細は後述する。一旦目標プロセスが選択され、繰り返し可能なベンチマークが保証されると、ベンチマークが起動される（ステップ６０８）。
【００５０】
ステップ６１０において、時間順に配列され、タイムスタンプを記されたすべてのヒープ・ページ・フォールトを記録するリストが作成され、補助記憶装置１３８に記憶される。このリストは、データ分析機構５０４による将来の使用のため各ページ・フォールトに関するすべての関連情報を含む。
【００５１】
ステップ６１２において、時間順に配列され、タイムスタンプを記されたすべてのヒープ・トランザクションを記録するリストが作成される。本発明の好ましい実施形態のＵｎｉｘ環境において、このリストは、malloc(), calloc(), realloc()および free()に対する呼び出しなどのトランザクションを含む。このリストは、割り当てられたサイズ、割り当てられたアドレス、解放されたアドレスおよびプロシージャ呼出しトレースを含む各トランザクションについてのすべての関連情報を含む。上記ステップの各々の詳細を以下に記述する。
【００５２】
1. 首尾一貫したベンチマークの実行
ステップ６０４に関連して記述したように、すべてのメモリ調整プロジェクトの進行を客観的に測定するために、首尾一貫した、繰り返し可能なベンチマークが必要である。本発明のベンチマークは、従来型のベンチマークとは相違する。多くのベンチマークは、１つまたは２つのプロセスを扱う。一方、ステップ６０４において作成されるベンチマークは、同じプロセス間順序で同じ動作を常に実行する複数のプロセスを伴う。これは、実行毎のページ・フォールトの変化を最小にする。
【００５３】
好ましい実施例の１つでは、記録されたユーザ・セッションがベンチマークの役目を果たす。記録／再生装置１５２が、ディスプレイ装置１４８およびユーザ・インタフェース１５０におけるユーザ入力を記録する。次に、再生ツールが非常に正確にセッションを再生する。すべてのユーザ入力およびＸサーバ事象は、クライアントの動作を能動的に監視し、入力をただ受動的にＸサーバーへ送り出すことのないように、再生装置１５２で再生するのに必要な十分な時間をとらなければならない。ページ・フォールトを最大にする必要性は、要求再生環境および貧弱な記録環境に関して生じる。従って、ページ・フォールト発生が少ないときベンチマーク記録が行われ、ページ・フォールト発生が多いとき再生が行われなければならない。しかし、ベンチマーク・システムが厳しいスラッシュ状態のときセッションを厳密に再生する記録／再生機構１５２は、可能な限り迅速にセッションを再生し、ユーザ入力における間隔を圧縮し、プロセス間動作の順序を維持するように構成される。
【００５４】
2. ページ・フォールトの最大化
ページ・フォールトの数および細分性を最大にすることは、ＡＷＳ決定機構５００の正確性を増加させ、観察されたページ・フォールトに基づいてその決定が行われるようにさせる。観察されるページ・フォールトが少ない場合、データ分析機構５０４によって処理されるために生成されるデータは少ない。本発明の好ましい実施形態においては、ページ・フォールトは、データ構造のアクセスの頻度を測定するメカニズムとして使用される。記憶されるべきページ・フォールト情報を評価する現存するカーネルがあるので、ページ・フォールトが選ばれた。
【００５５】
上述の通り、１ページを占める単一のデータ構造が存在する場合最良の結果が達成されるが、多くのケースにおいては、複数のデータ構造が同一のページを占有する。そのようなページが一度だけフォールトを発生すると、ただ１つの構造だけが観察され、残りは隠れてしまう。ページのスワップ・イン、スワップ・アウトが多くなればなるほど、これらの隠れた構造を観察できる確率は高まる。例えば、頻繁にアクセスされるデータ構造の２つのタイプＡおよびＢがともにメモリ全体にわたって拡散している（すなわち局所性が小さい）と仮定する。さらに、特定のベンチマークについて、これらのデータ構造が同一セットのページを占めていると仮定する。ページ・フォールトが最大化されていないならば、ベンチマークのアクセス様態に基づいて異なるシナリオが生じる可能性がある。例えば、両タイプの構造は、その共有ページに関して、フォールトを分割するであろう。明きらかに、その２つのうちの１つがフォールトのすべてを消費する。もう一つの可能性は、もう一方の構造がフォールトのすべてを消費することである。これらのシナリオはデータ構造のタイプを隠蔽し、そのため、その発生をデータ記録機構５０２が記録することが妨げられる。
【００５６】
本発明の好ましい実施形態では、１つの構造だけが各ページを占める。これらのページが常にその使用後直ちにスワップ・アウトされるならば、これらの構造が受け取るフォールトの数は、それらが使用される頻度を示す。例えば、２つの構造ＣおよびＤを仮定し、軽度のページングの間ＣおよびＤそれぞれが１回だけのページ・フォールトを受け取り、重度のページングの間Ｃが２回のページ・フォールトを、Ｄが２０回のページ・フォールトを受け取るとする。明らかに、ＤはＣよりいっそう頻繁に使用されている。
【００５７】
いくつかのアプローチによって、ベンチマーク実行５０８の間のページ・フォールトの数および細分性を増加させることができる。最も簡単なものは、システムＲＡＭ１３６の量を減らすことである。これを実行する最も単純な方法は、システムの電源を切断し、ＳＩＭＭを取り出すことである。しかし、これは時間浪費的であり、ページ・フォールトの最適量に見合う細分性をたぶん生み出さないであろう。ページ・フォールトの最適数は、相対的に正確なＡＷＳ決定を行なうことができる程度のものではあるが、ベンチマークが受容不可能なほど長く行われるほど多数ではない。本発明の好ましいアプローチの１つは、カーネル１０８がアクセスするようにプログラムされるＲＡＭ１３６の量を、ユーザが、相対的に小さい増分値で指定することを許容する拡張カーネル１０８を使用することである。この点は、当業者の理解の範囲内にあるものとみなされる。
【００５８】
もう一つのアプローチは、メモリ管理モジュール１３４の事前ページ機能を取り外すことである。例えば、カーネル１０８は、フォールトを受けるページの周囲のページを、すぐに使用されるという予測のもと、取り込む場合がある。事前ページング機能は、通常動作の間はすぐれた機能であるが、ベンチマーク実行の間はそうではない。これは、事前ページング機能の目的がデータ構造アクセスを効果的に隠すことであるが、この点がまさに本発明のプロセスに対して相反するものであることによる。この点も当業者の理解の範囲内にあるものと考えられる。
【００５９】
本発明のもう１つの好ましい実施形態において、複数の方法が使用され、それによりデータ記録機構５０２が非常に精度の高い結果を達成する。この好ましいアプローチの第１の部分は、特定のプロセスを対象とする特別のカーネルを使用することである。すべてのプロセスの処理速度を遅くするシステムＲＡＭ減少の方法に代わって、上記特別のカーネルが、ＣＰＵメモリ管理モジュール１３４にただ１つのヒープ・ページを配置する。これを行うため、ＲＡＭにあるプロセスのページのすべてにキーを付け、ＲＡＭには単一のページしかないと信じ込ませるようにメモリ管理モジュール１３４を修正する。対象とされたプロセスは、それが異なるヒープ・ページをアクセスする度毎にフォールトを発生させる。殆どの隠れたデータ構造が見い出されるだけでなく、各データ構造使用の観察頻度も相対的に正確である。処理能力を最大にするため、カーネルは、プロセスのヒープ・ページをＲＡＭに置き、各ページ・フォールトを非常に迅速に処理するように構成される。この点も当業者の理解の範囲内にあるものと考えられる。
【００６０】
本発明の好ましいアプローチの第２の部分は、これもまた独立して利用されるものであるが、ページ・フォールトを特定のデータ構造に対応させるものである。例えば、本発明の好ましい実施形態が実施されるＵｎｉｘ環境において、２つのデータ構造が同じページを共有しないようにｍａｌｌｏｃライブラリが修正される。このようなｍａｌｌｏｃの変更は、当業者の理解の範囲内にあるものと考えられる。上述の拡張カーネルと連係して使われるとき、データ記録機構５０２の正確度はほぼ完全になる。
【００６１】
3. ページ・フォールトの記録
上述の通り、データ記録機構は，プロセスが厳しいスラッシュ状態のときページ・フォールトを観察する。各ページ・フォールトについて、データ記録機構５０２は、すべてのヒープ・ページ・フォールトについての情報を、時間順の、タイムスタンプ付きリストに記録する。図７に示すように、以下の情報が、ステップ６１０で記録される。第１に、ページ・フォールト７０２を引き起こしたアドレスが記録される。これは、ページ・フォールトが起きたときにアクセスされていたアドレスである。本発明は、データ構造を記録して、分析する。しかし、本発明がプログラム・コードに対するものであるとすれば、通算されるプログラムが記憶されるであろう。加えて、プログラム・カウンタ値７０４およびページ・フォールト７０２が記憶されるであろう。これは、ページ・フォールトを起こしたプロシージャのアドレスである。
【００６２】
好ましい実施形態において、カーネル１０８はＨＰ−ＵＸカーネルである。ＨＰ−ＵＸカーネルは、特別測定情報バッファに上述の情報を提供する。それに加えて、データ記録ツールは、既にカーネル１０８に存在していた。カーネル１０８のこの既存の記録機構に対する変更は必要であったが、これは当業者の理解の範囲内にあるものと考えられる。この記録ツールが相対的に小さく目立つものでない点に留意する必要がある。
【００６３】
4. ヒープ・トランザクションの記録
上述のように、ステップ６１０において、時間順に配列され、タイムスタンプを押されたヒープ・トランザクションのリストが作成される。上述の通り、カーネル１０８の好ましい実施形態は、Ｕｎｉｘカーネルである。ステップ６１０において、データ記録機構５０２は、Ｃプログラミング言語の動的割り当てライブラリに対する呼び出しの各々に関するすべての情報を記録する。これは、malloc(), calloc(), realloc()および free()に対する呼び出しを含む。しかし、当業者に明らかなように、本発明は、所望の高水準言語の動的割り当てライブラリに対する呼び出しを記録するように構成することができる。
【００６４】
図８に示すように、各ヒープ・トランザクションについて記録される情報は以下を含む。ヒープ・トランザクション情報は、割当て／解放状態８０２を含む。この状態は、メモリが割り当てられたか、あるいは解放されたかを示す。ヒープ・トランザクション情報は、また、割り当てられたブロックのサイズ８０４を含む。ヒープ・トランザクション情報には、また、割当て／解放アドレス８０６が含まれる。最後に、プロシージャ呼出しトレース・データ８１０が記録される。これは、各トレース行毎に以下の情報を含む。プロシージャ名８１２、あるプロシージャを別のものと区別するプロシージャの開始点からのオフセット８１４、およびプロシージャの原始ファイル８１６である。
【００６５】
第１に困難な点は、i)プロシージャ・トランザクション・トレースを迅速にかつ正確に決定すること、および ii)トランザクション別情報を迅速にかつ正確に記録する形式を設計することであった。Ｘサーバの起動（すなわちクライアントは何も実行されてない）に関する情報を記録する最初の試みは、約１７Ｍバイトを記録するのに約３０分を要した。最初の試みは、全トレースに関して全面的なＡＳＣＩＩストリングを作成する一般的ＨＰ−ＵＸトレース・ユーティリティを使用したが、それが大部分の時間と空間を占有した。
【００６６】
本発明の好ましい実施形態では、プロセッサ１４２はヒューレット・パッカードのＰＡ−ＲＩＳＣシステムであり、カーネル１０８はＨＰ−ＵＸ Ｕｎｉｘオペレーティング・システムである。ＨＰ−ＵＸに関し正確なトレースを作成することは、ＰＡ−ＲＩＳＣの共有ライブラリのため、困難である。従って、好ましい実施形態においては、アドレスのアレイを戻す特製ユーティリティが使われる。プログラムのシンボル・テーブルにあるプロシージャ名とこれらのアドレスの関連づけは、後処理まで延期された（これはベンチマーク実行の間、効果的で邪魔になるようなものではないことが判明した）。最終的な記録形式は、冗長でないバイナリ形式であった。最終的な解は、２のオーダーでメモリ空間を効率的に使用し、上記最初の試みより３のオーダーで処理時間を効率化した。
【００６７】
次に、ほとんどのプログラムが使用するmalloc()のバージョンを含んだlibc共有ライブラリを修正することが重要であった。ヒープ・トランザクション情報にタイムスタンプを押すことは、ヒープ・データをカーネル１０８に渡すことによって成し遂げられる。カーネルはデータにタイムスタンプを押し、それを上述の特別測定値インターフェース・バッファ中でページ・フォールト・データとマージする。これによって、１つのデータ記録ツールですべての情報を記録することができる。
【００６８】
B. データ分析機構５０４
データ分析機構５０４は、ベンチマークの間データ記録機構５０２によって記録された大量のデータを効率的に処理する対話型情報処理ツールである。データ分析機構５０４は、また、ユーザが、処理されたデータを対話型で活用して、プロセスのヒープＡＷＳに対する詳細な分析を行うことを可能にする。図９は、データ分析機構５０４によって実行される主プロセスの流れ図である。
【００６９】
1. ヒープトランザクションのＣデータ構造タイプへの関係づけ
上述の情報が各ヒープ・トランザクションについてデータ記録機構５０２によって記録されると、データ分析機構５０４は、ヒープ・メモリの各ブロックを特定のＣデータ構造タイプに関係づける（ステップ９０４）。詳細は後述するが、この関係づけは、記録された情報を一組の規則と比較することによって達成される。ステップ９０４の関係づけを、サンプルＸサーバにおけるサンプルのデータ構造タイプを用いて説明する。サンプルＸサーバは、装置従属型ドライバを持つワークステーション・ユーザに対するサーバのサンプルである。サンプルＸサーバは、米国マサチューセッツ州ケンブリッジ所在のX Consortium社から入手できる。
【００７０】
図１０は、ウィンドウ構造を作成するためのプロシージャ呼出しトレースを示す。サンプルＸサーバの中の最も重要なデータ構造タイプの１つは、WindowRec構造（または単にウインドウ構造）である。構造のサイズは、多数画面のＸサーバにおいて可変的であるが、単に２つの独特なプロシージャ呼出しだけがトレース・ウインドウ構造を作成するために使われる。図１０に示される通り、その２つは、ルート・ウインドウを作成するためのプロシージャ呼出しトレース１００２、およびクライアント・ウインドウを作成するためのプロシージャ呼出しトレース１００４である。しばしば、各Ｃデータ構造タイプは、本例で示されるものより単純な１つの独特な割り当てトレースだけを持つことがある点に留意する必要がある。
【００７１】
プロシージャ呼出しトレース１００２は、図１０において左側の列に示されている。ルート・ウィンドウを作成するため以下のプロシージャ呼出しが行われた。Malloc()プロシージャ呼び出し１００６は、Xalloc()プロシージャ呼出し１００８によって呼び出された。Xalloc()プロシージャ呼び出し１００８は、AllocateWindow()プロシージャ呼出し１０１０によって呼び出された。AllocateWindow()プロシージャ呼び出し１０１０は、CreateRootWindow()プロシージャ呼出し１０１２によって呼び出された。CreateRootWindow()プロシージャ呼び出し１０１２は、Main()プロシージャ呼出し１０１４によって呼び出された。
【００７２】
プロシージャ呼出しトレース１００４は、図１０において右側の列に示されている。クライアント・ウィンドウを作成するため以下のプロシージャ呼出しが行われた。Malloc()プロシージャ呼び出し１０１６は、Xalloc()プロシージャ呼出し１０１８によって呼び出された。Xalloc()プロシージャ呼び出し１０１８は、AllocateWindow()プロシージャ呼出し１０２０によって呼び出された。AllocateWindow()プロシージャ呼び出し１０２０は、CreateWindow()プロシージャ呼出し１０２２によって呼び出された。CreateWindow()プロシージャ呼び出し１０２２は、ProCreateWindow()プロシージャ呼出し１０２６によって呼び出された。ProCreateWindow()プロシージャ呼び出し１０２６は、Main()プロシージャ呼出し１０２４によって呼び出された。
【００７３】
図１０を参照して明らかなように、各トレースの中の最初の３つのプロシージャは同一である。すなわち、プロシージャ呼出し１００６、１００８および１０１０は、それぞれプロシージャ呼出し１０１６、１０１８および１０２０と同一である。これは異常ではない。実際、最初の２つと最後の２つプロシージャは、ほとんどのＸサーバ・データ構造タイプについてしばしば同一である。従って、トレースの真ん中のプロシージャに一般的に関心が払われる。この例では、AllocateWindow()が両方のトレースにある。AllocateWindow()は、Xalloc()の呼び出しを１回だけ行うので、トレースにおけるAllocateWindow()をもつヒープ・トランザクションはウインドウ構造である。
【００７４】
本発明において、Ｃデータ構造タイプを識別する好ましい方法は、1つまたは複数の規則を有する。規則は、データ構造タイプの割り当て／解放トランザクションの様相を示す仕様である。規則は、当業界でよく知られているもので、「正規表現(regular expresions)」に類似している。規則のセットには、名前（典型的には構造タイプ名）が与えられる。これらの規則が各ヒープ・トランザクションと比較される。それらは、どのトランザクションがどのＣデータ構造タイプに対応するかを決定するためにデータ分析機構５０４が使う選択基準である。ある規則があるトランザクションと一致すると、対応するヒープ・ブロックが識別される。データ分析機構５０４は、規則メモリ５０６および規則エディタ５０８を通して、このアプローチを対話型形態で実行する。
【００７５】
本発明の好ましい実施形態において使われる規則によって、各データ構造を１回以上識別することができる。データ構造タイプ名の階層を持つことが役に立つ場合がある。例えば、ピックスマップ（すなわちpixmap）が、サンプルＸサーバにおいて（例えば補助記憶、タイル、点描など）様々な目的のために使われる。従って、ある１つのセットの規則がすべてのピックスマップを識別することができ、その他のセット規則がピックスマップの特定タイプを識別することができる。
【００７６】
大量の構造タイプをもつプログラムについては、規則作成は時間浪費的である。規則作成を容易にするため、データ分析機構５０４は規則管理モジュール５０６を使用して、ユーザが規則のセットを対話型で管理することを可能にする。更に、規則エディタ５０８には、ユーザが対話型で規則を作成し編集できるダイアログが含まれる。規則作成および管理を容易にするため、規則管理モジュール５０６および規則エディタ５０８のその他の既知の機能が利用される。例えば、規則の各部分は、ワイルドカードとすることができる（ワイルドカード機能についての詳細は後述する）。これは、各規則の能力を増加させ、規則作成時間を減少させる。加えて、規則ファイルは、データ分析セッションの間規則を維持するように読み取られ書き込まれる。規則エディタ５０８を使用して数多くの方法でヒープ・トランザクションを検討することができる。例えば、ユーザは、検討するトランザクションの初期値にセットされている初期値を用いて規則エディタの使用を開始することができる。
【００７７】
図１０で示されるウインドウ構造のサンプルを使用して、各割り当てトランザクションについてのトレースには、AllocateWindow()プロシージャが含まれた。更に、AllocateWindow()プロシージャ１０１０，１０２０は、ウインドウを作成するためXalloc()１００８，１０１８に対してただ１回の呼び出しを行った。従って、ウインドウ構造を識別する明白な規則は、そのトレースがAllocateWindowという語を含むトランザクションである。トランザクションの他のいかなる部分もこの規則の中で指定されず、すべての値は、ある規則のワイルドカードとされた部分のすべてと一致するものとみなされる点注意する必要がある。
【００７８】
好ましい実施形態において、いくつかの識別されない構造が多くのページ・フォールトを引き起こす場合、メニュ選択機能が、規則エディタ・ダイアログを画面表示し、そこに構造割り当てトランザクションの値にセットされた初期値を表示する。初期規則値は、(例えばもっと一般化するため）編集し、（実際のＣデータ構造タイプ名のような）名前を与えることができる。規則が保存されるとき、すべての一致するメモリ・ブロックを識別するため、その規則はすべてのトランザクションと比較される。ユーザは、そのタイプのあらゆるデータ構造について情報を調べることができる。
【００７９】
2. 情報処理
ベンチマークが完了し、上述の情報が記録され互いに関連づけられた後、情報処理ステップが実行され、そこで、対象とされたプロセスのヒープＡＷＳのおよその決定が行われる。以下に、記録され関連づけされた情報を処理するための一般的アルゴリズムを記述する。最初に、ステップ９０６において、トランザクション・データは、データ分析に適する形式になるように処理される。ステップ９０６のトランザクション処理は、図１１を参照してさらに詳細に後述する。次に、一般にページ・フォールト処理と呼ばれる一連の機能がステップ９０８で実行される。ステップ９０８において、ページ・フォールトデータが読み込まれヒープ・トランザクション・データと関連づけらる。対応するデータ構造とページ・フォールトの間の結合が設定される。この詳細は図１２を参照して後述する。
【００８０】
a. トランザクション処理(ステップ９０６)
ヒープ・トランザクション・データに対して実行される処理を図１１を参照して説明する。最初に、ステップ１１０４において、対象とされるプロセスのシンボル・テーブルが、（ハッシュ・テーブルのような）便宜的データ構造に読み込まれる。次に、ヒープ・トランザクション・データが読み取られ処理される。
【００８１】
次に、ステップ１１０６において、各ヒープ・トランザクションは、割り当てまたは解放トランザクションとして識別される。各割り当てトランザクションの割り当てアドレスはハッシュされる。これは、割り当てそして解放するトランザクションと突き合わせるステップ９０８に関連するソフトウェアを単純化する。トランザクションの一致するセットが見つけられると、それらは交差リンクされる。
【００８２】
ステップ１１０８において、トレースの各行は、プロシージャ名、ファイル名およびプロシージャの範囲内のオフセットに変換される。トレースの各行が単にアドレスとして記録されているため、プロシージャ名は必要である。オフセットは、プロシージャの開始点からのバイト数である。トレースの各行は複数回観察されることができるので、各行はハッシュ・テーブルに入れられる。このハッシュ・テーブルは、トレース行それぞれ毎に３２ビットのキーの値を生成する。これは、データ分析機構５０４が記憶するデータをデータ分析機構が更に処理を行う（ステップ１２０６）時間を減少させる。ステップ１１０８において、各トレースは、トレース行キーのアレイとして記憶される。トレース行と同様に、各トレースもまた、ハッシュ・テーブルに入れられ、独特のトレースのため独特のキーの値が生成される。各トランザクションは、そのトレースに関しユニークなキーを記憶する。
【００８３】
b. ページ・フォールト処理（ステップ９０８）
図９を参照して述べたように、トランザクション・データが処理され、データ分析に適した形式にされた後、ページ・フォールトがステップ９０８で発生するかもしれない。図１２は、ステップ９０９でページ・フォールト処理を行う際に実行されるステップの流れ図である。図１２を参照して、本発明の好ましいページ・フォールト処理を説明する。
【００８４】
ステップ１２０４において、各解放トランザクションは、その対応する割り当てトランザクションと突き合わせられる。これは、ヒープ・ブロックが割り当てられた時間間隔を識別する。割り当てトランザクションと合致する解放トランザクションが記録されていなければ、対応するメモリ・ブロックは、潜在的なメモリ漏洩である。
【００８５】
次に、ページ・フォールトを起こしたＣデータ構造と、ページ・フォールトの各々が関連づけられる。最初に、ステップ１２０６において、データ構造タイプが、規則を使用して、関連づけられたヒープ・メモリ・ブロックと突き合わせられる。次に、ステップ１２０８において、ページ・フォールトのアドレスが、時間を越えてすべての対応するメモリ・ブロックと突き合わせられる。１つ以上の一致があれば、ステップ１２１０において、タイムスタンプの比較を行って、どのデータ構造がページ・フォールトを起こしたかを決定する。このように、ヒープ情報と各フォールトを起こしたアドレスとの比較を、特定のデータ構造と一致するまで行う。ページ・フォールト・プロセスは、ブロック１２１２で終了する。
【００８６】
例えば、特定のフォールトがベンチマーク実行の１３分で発生すると仮定する。フォールトを起こしたアドレス（Ｏｘ４ＯＯａｂ３４０)は、ヒープ・トランザクションの３つの異なるペアのアドレス範囲内にある。タイムスタンプを比較した後、どのペアがページ・フォールトに対応するかが明らかになる。この新たな相互参照情報のすべてが、ＡＷＳに関する詳細を得るために分析されることができる。
【００８７】
c. ユーザの分析
ステップ９０８でページ・フォールト処理が完了すると、データは多くの異なる形態で分析されることができる。データは、度数分布を用いて分析するため（例えばページ・フォールト数や構造のサイズで）ソートすることができる。各度数分布図の行が選択され、付加情報が要求される。局地性をを示すため、選択されたデータ構造のサイズと配置を視覚的に示す「メモリマップ」グラフを表示することもできる。
【００８８】
d. 規則の突き合わせ
規則は、作成されるかあるいは規則ファイルから読み取られるときは必ず、トランザクションと突き合わせられる。トランザクション・データベースの構造は、規則突き合わせを容易に行えるように構成される。
【００８９】
第１に、規則の各行は、トランザクション・データベースの各トレース行と比較される。一致が見つかれば、ユニークなキーが記録される（注：ワイルドカードのため、ある規則行は、複数のトレース行と一致する場合がある）。どの規則行も一致するトランザクションを見つけれない場合、規則全体がこのトランザクションと合致しないので、この規則に関する処理は停止する。
【００９０】
規則行が一致したあと、トレース規則が、トランザクション・データベースのユニークなトレースの各々と比較される。一致するトレース毎に、ユニークなキーが記録される。次に、トランザクション（複数）自体が、全体の規則と比較される（トレースの比較は、単純な３２ビットキーの整数比較である）。規則と一致トランザクションの間の交差結合が確立され、それによってデータ分析の対話型データ分析の処理能力が向上する。
【００９１】
上述の通り、本発明の好ましい実施形態において、プロセスのデータ構造が記録され分析される。しかし、当業者に明らかなように、本発明のＡＷＳ決定機構５００は、プロセスのコードや大局変数のようなプロセスのその他の特性を記録しそして分析するように構成することも可能である。
【００９２】
本発明の好ましい実施形態において、データ分析機構５０４は、ベンチマーク実行が完了し、データ記録機構が必要な情報を記憶した後その機能を実行する。しかし、当業者に明らかなように、データ分析機構５０４は、別のプロセッサに配置され、データ記録機構５０２とリアルタイムで動作することもできよう。例えば、コンピュータ・システム１００がネットワークに接続するような実施形態において、データ記録機構５０２によって記録されるデータは、ネットワークを介してコンピュータ・システム１００と通信する記憶装置に記憶されることもできる。また、コンピュータ・システム１００がネットワークに接続しているとき、データ分析機構５０４が別のコンピュータ・システムに配置され、ベンチマーク実行の完了後データ分析機能を実行することもできる。
【００９３】
上記の説明において、Ｃ言語およびＨＰ−ＵＸ Ｕｎｉｘ環境を参照して本発明を記述した。しかし、当業者に明らかなように、本発明は、Fortranのようないかなる高水準プログラミング言語に関しても動作することができる。それに加えて、本発明は、Ｗｉｎｄｏｗｓ／ＮＴ、ＶＭＳ、Ｏｐｅｎ ＶＭＳ、Ｔ／２０などいかなるオペレーティング・システムにおいても動作することができる。データ記録機構５０２およびデータ分析機構５０４を含むＡＷＳ決定機構５００は、（実行時に）主メモリ１３６に駐在しプロセッサ１４２のようなコンピュータ・システム１００のプロセッサによって実行されるコンピュータ・プログラムおよび／またはライブラリを好ましくは意味する。データ記録機構５０２によって記録されるデータは、補助記憶装置１３８に記憶することもできる。また、ＡＷＳ決定機構５００に関連するコンピュータ・プログラム／ライブラリは、フロッピーディスクまたは他の取り外し可能記憶媒体に記憶される場合もある。
【００９４】
本発明は、ハードウエア、ソフトウエアまたはそれらを組み合わせた形態のいずれでも実施することができる点理解されるべきであろう。そのような実施形態では、種々の構成要素とステップが、本発明の機能を実行するためハードウェアやソフトウェアで実施される。現存または将来開発されるコンピュータ・ソフトウェア言語およびハードウェア・コンポーネントのいずれも本発明の実施形態において使用することができる。
【００９５】
VI. 事例研究（ＡＷＳ決定機構を使用したＨＰ Ｘサーバのメモリ調整）
ＨＰ Ｘサーバのメモリ調整を行うＡＷＳ決定機構５００の実施例を以下説明する。事例研究で使用するサンプルＸサーバは、上記引用のＸ ConsortiumのＸサーバ（リリース５）である。Ｘ Consortiumのスタッフによって、本発明を使用することなく、若干の事前メモリ調整が行われた。その作業にもかかわらず、なお改善の余地があった。
【００９６】
A. ウインドウ局地性
ウィンドウ関連構造に関し３つのタイプの改善が行われた。第１に、ウィンドウ・ツリーの局地性が、汎用目的ライブラリ呼び出しのChunkAllocの使用によって改善された。第２に、ウィンドウ・プライベート構造のサイズが減らされた。最後に、Window0ptRecデータ構造の局地性が再びChunkAllocを使用して改善された。
【００９７】
前述のように、各ウィンドウ構造は個別に割り当てられる。ウィンドウ（複数）は、その階層（すなわちツリー）関係に従って互いに結合される。ウィンドウ・ツリーは、比較的頻繁に変化する。直感的に見れば、構造の相互の局地性は小さく、そのためＸサーバのＶＷＳを増加させ、不必要なページ・フォールトを発生させる。ＡＷＳ決定機構５００は、この直観を確認した。データ記録機構ベンチマークは、ウインドウ構造が（ＡＷＳにおいて）頻繁にアクセスされ、（ＶＷＳを増加させる）貧弱な局地性を持つことを明らかにした。ChunkAllocと呼ばれるライブラリを使用してウインドウをグループで割り当てるようにＸサーバが変更された。
【００９８】
B. サイズの減少
新たに改善された局地性に加えて、ＡＷＳ決定機構５００は、ウィンドウ構造がかなり大きいことを示した。これは、各ページに適合するウィンドウが相対的に少ないことを意味した。従って、各ウィンドウ・ツリーの探索に、多数のページのアクセスを要した。ＨＰ Ｘサーバは、最近その処理能力の大幅な改善が行われた。ＤＤＸコードの完全に新しい世代が開発された。しかし、新しいＤＤＸコードは、前世代からのプライベート構造をなお使用していた。それらの古いプライベート構造からはただ２、３のフィールドだけが使われ、各ウインドウについて相当のメモリが無駄に使われていた。プライベート構造の再構成の後、さらに新たにされたＤＤＸコードは、ウィンドウ当たり２００未満バイトを使用した。ChunkAllocと組み合わせたとき、ウィンドウは局地的でかつ小さくなり、従って、ページ・フォールトは少なくなった。
【００９９】
C. WindowOpt局地性
コアＸ１１プロトコルは、各ウィンドウに関する数多くの属性を指定する。Ｒ４を使用した検討の間、ほとんどのウィンドウが属性のいくつかを使用していないことが指摘された。このため、Consortiumスタッフはウィンドウ構造を分割した。彼らは、あるウインドウがあまり使用されない属性を使用する場合割り当てられる新しい構造WindowOptを作成した。ＡＷＳ決定機構５００は、（少なくとも特定のベンチマークのため）ウインドウの相当の割合がWindowOpt構造を使用することを容認した。ＡＷＳ決定機構５００は、また、主ウィンドウ構造の場合と同様に、局地性の問題を明らかにした。従って、ChunkAllocライブラリを使用して局地性を改善した。
【０１００】
D. 資源の局地性
Ｘ１１のクライアント／サーバ特性を所与とすれば、クライアントは、サーバ内部のデータ構造を直接参照しない。その代わり、クライアントは、資源識別子を使用して、それらの構造（すなわち資源）にはたらきかける。サーバは、資源識別子といくつかの内部データ構造の間の対応関係を含む資源データベースを維持する。データベースの中の各資源毎に、小さい１６バイトのデータ構造が割り当てられる。ＡＷＳ決定機構５００は、これらの小さい構造が頻繁に処理され、多くのページ・フォールトを発生させたことを明らかにした。これらの構造のメモリ・マップを参照することが明確な局地性問題を示した。再び、ChunkAllocを使用した。局地性が増加し、ページ・フォールトが減少した。
【０１０１】
E. フォント
本発明の使用により、ビットマップ・フォントを開くコードが非常に浪費的であることが明らかにされた。１つのビットマップ・フォント（ファイル）が開かれる毎に、１つの大きい構造（約８０ＫＢ）と多くの小さい構造が割り当てられ、使われ、次に解放された。各ビットマップ・フォントが開かれる時間の間に他の動作が発生したため、これらの一時的構造はヒープを断片化し、他のＡＷＳ構造の局地性を減少させた。ビットマップ・フォント・コードが実行しようとしたことを調査の結果、データ構造は偶然大きかったことが明らかになった。それは、８０ＫＢでなく２−３ＫＢあれば十分であった。小さいユーティリティ・ライブラリを作成して、比較的大きく比較的常駐するメモリの一時的構造を小さく割り当てるようにした。これによって、断片化が更に減少した。非一時的フォント構造についてこれと同じライブラリを使うことによってさらに局地性が改善された。
【０１０２】
VII. 結論
本発明が好ましい実施形態を参照して例示され説明されたが、本発明の精神と範囲を逸脱することなく、その詳細および形式を種々変更することが可能である点は当業者によって理解されるであろう。
【０１０３】
本発明には、例として次のような実施様態が含まれる。
（１）仮想メモリ・コンピュータ・システムにおいてプロセスの実際ワーキング・セットを決定するためのシステムであって、一貫性のある複数のベンチマークの実行を通して、動的に割り当てられたトランザクションおよび仮想メモリのページ・フォールトに関する情報を記録するデータ記録機構と、上記データ記録機構に接続し、動的に割り当てられたメモリのブロックの各々を特定の高水準言語データ構造に関連づけるデータ分析機構と、を備えるシステム。
（２）上記データ記録機構が、時間順に配列され、タイプスタンプを付されたページ・フォールトのリストおよび時間順に配列され、タイプスタンプを付されたページ・トランザクションのリストをコンパイルする手段を有し、上記データ分析機構が上記ページ・フォールトのリストとページ・トランザクションのリストを関係づける手段を有し、上記ページ・トランザクションを１組の規則と比較することによってページ・トランザクションがデータ構造タイプと関連づけられ、上記規則の各々が、上記データ構造タイプの１つについて、割り当てそして解放する一連のトランザクションを定義し、更に、上記データ分析機構が、割り当てトランザクションおよび解放トランザクションを識別するためのトランザクション処理手段と、上記ページ・フォールトのリストとページ・トランザクションのリストを関係づけ、ページ・フォールトと関連高水準データ構造の間の結合を形成するためのフォールト処理手段とを有する、上記（１）に記載のシステム。
（３）上記フォールト処理手段が、上記高水準データ構造に、上記フォールトの各々を発生させたコード・プロシージャを関係づける手段を含む、上記（１）に記載のシステム。
（４）仮想メモリ・コンピュータ・システムが、オペレーティング・システム・カーネルおよび物理メモリを含み、上記オペレーティング・システム・カーネルがプロセスの仮想ページの１ページだけを上記物理メモリに保持し、それによって、上記１ページの仮想ページ以外の仮想ページがアクセスされる毎にフォールトを発生させる、上記（１）に記載のシステム。
（５）上記データ分析機構が、上記１組の規則を対話型で処理する規則管理モジュールと、規則を対話型で作成し編集する規則エディタを有する、上記（１）に記載のシステム。
【０１０４】
（６）メモリ調整機能を強化するため、仮想メモリ・システムにおいて動的に割り当てられたデータ構造を持つプロセスの実際ワーキング・セットを決定する方法であって、プロセスに関し高率のページ・フォールトを誘発するステップと、当該プロセスについて反復可能なベンチマークを実行するステップと、時間順に配列され、タイプスタンプを付されたページ・フォールトのリストおよび時間順に配列され、タイプスタンプを付されたページ・トランザクションのリストのコンパイルを含むプロセス情報を記録するステップと、ヒープ・メモリのブロックを上記データ構造に関係づけるため上記プロセス情報データを分析するステップと、を含み、上記プロセス情報データを分析するステップが、各々が上記データ構造タイプの１つについて割り当てそして解放する一連のトランザクションを定義しする１組の規則と上記ページ・トランザクションを比較することによってページ・トランザクションがデータ構造タイプと関連づけられように、上記プロセス情報を関係づけるステップと、プロセスの実際ワーキング・セットを決定するため上記プロセスおよび上記関係づけられた情報を処理するステップとを含み、更に、上記プロセスおよび上記関係づけられた情報を処理する上記ステップには、割り当てトランザクションおよび解放トランザクションを識別することを含むトランザクション処理と、上記ページ・フォールトのリストとページ・トランザクションのリストを関連づけ、ヒープ・メモリの上記ブロックとデータ構造の間の結合を形成することを含むフォールト処理とが含まれる、実際ワーキング・セットを決定する方法。
（７）仮想メモリ・システムが、複数の仮想メモリ・ページを持ち、上記高率フォールトを誘発するステップが、上記仮想ページの各々に対してただ１つのデータ構造を持つことによって実行される、上記（６）の方法。
（８）仮想メモリ・システムが、オペレーティング・システム・カーネルと物理メモリを含み、上記高率フォールトを誘発するステップが、上記オペレーティング・システム・カーネルによってプロセスの仮想ページ１ページだけが上記物理メモリに保持されることによって実行され、それにより、上記１ページの仮想ページ以外の仮想ページがアクセスされる毎にフォールトが発生する、上記（６）に記載の方法。
（９）上記ページ・トランザクションのリストが、メモリのブロックが割り当てられているか、また上記ブロックが解放されているかを示すメモリ状態データ、ブロック・サイズ・データ、ブロック・アドレス・データ、タイムスタンプ、およびプロシージャ名、プロシージャ・オフセットならびにプロシージャ原始ファイル名を含むプロシージャ呼出しトレース・データを含む、上記（６）に記載の方法。
【０１０５】
（１０）上記フォールトを処理するステップが、データ構造に、上記フォールトの各々を発生させたコード・プロシージャを関係づけるステップを含む、上記（６）に記載の方法。
（１１）上記ページ・フォールトのリストが、ページ・フォールト・アドレスおよびページ・フォールト・タイムスタンプを含む、上記（６）に記載の方法。
（１２）上記プロセス情報が、プロセスの大域変数に関連するデータを含み、上記フォールト処理ステップが、上記大域変数に対するアクセスを上記ページ・フォールに関係づけるステップを含む、上記（６）に記載の方法。
（１３）上記プロセス情報が、プロセスのプログラムコード・プロシージャに関連するデータを含み、上記フォールト処理ステップが、上記プロシージャに対する呼び出しを上記ページ・フォールに関係づけるステップを含む、上記（６）に記載の方法。
（１４）上記プロセス情報が、プロセスの静的に割り当てられたオブジェクトに関連するデータを含み、上記フォールト処理ステップが、上記オブジェクトに対するアクセスを上記ページ・フォールに関係づけるステップを含む、上記（６）に記載の方法。
（１５）上記トランザクションを処理するステップが、ハッシュ・テーブルにプロセスのシンボル・テーブルを読み込むことを含む、上記（６）に記載の方法。
（１６）上記フォールト処理ステップで結合されたデータを画面表示するステップを含む、上記（６）に記載の方法。
（１７）上記フォールト処理ステップが、上記割り当てトランザクションの各々を上記解放トランザクションの１つと突き合わせるステップと、上記ページ・フォールトの各々をデータ構造の１つに関係づけるステップとを含む、上記（６）に記載の方法。
（１８）上記フォールト処理ステップが、上記解放トランザクションの１つが上記割り当てトランザクションの１つと合致しない場合、潜在的メモリ漏洩を示すステップを含む。上記（６）に記載の方法。
【０１０６】
【発明の効果】
本発明のＡＷＳ決定機構によって、プロセスに動的に割り当てられるメモリ・ワーキング・セットについて、実際に頻繁に使用される部分を特定することが可能となり、その分析結果を活用してプロセスのメモリ調整を行うことによって、マルチタスク仮想メモリ環境におけるシステム処理能力の向上を図ることができる。
【図面の簡単な説明】
【図１】本発明が実施される好ましいコンピュータ環境を示すブロック図である。
【図２】物理メモリと仮想メモリの間の関係を示すブロック図である。
【図３】システムＲＡＭおよび補助メモリに仮想メモリが記憶される形態をとる仮想メモリ・システムの例を示す図である。
【図４】プロセスの仮想ワーキング・セット（ＶＷＳ）および実際ワーキング・セット（ＡＷＳ）を示すブロック図である。
【図５】本発明の実際ワーキング・セット決定機構の処理ステップを示すブロック図である。
【図６】本発明ののデータ記録機構によって実行されるデータ記録プロセスの流れ図である。
【図７】典型的なベンチマーク実行の間記録されるページ・フォールト・データのテーブルを示す図である。
【図８】典型的なベンチマーク実行の間記録されるヒープ・トランザクション・データのテーブルを示す図である。
【図９】本発明のデータ分析機構によって実行されるデータ分析プロセスの概要を示す流れ図である。
【図１０】ウィンドウ構造を作成するためのプロシージャ呼出しトレースのテーブルを示す図である。
【図１１】本発明のデータ分析機構によって実行されるトランザクション処理の流れ図である。
【図１２】本発明のデータ分析機構によって実行されるページ・フォールト処理の流れ図である。
【符号の説明】
１００ コンピュータ・システム
１０６ ユーザ・アプリケーション・レベル
１０８ カーネル・レベル
１１０ ハードウエア・レベル
１３６ 主メモリ
１３８ 補助メモリ、または補助記憶装置
２０２ 物理メモリ
２０４ 仮想メモリ
２０６ スワップ空間
２１０、４０２ ページ
４０４ 仮想メモリ・ワーキング・セット（ＶＷＳ）
４０６ 実際ワーキング・セット（ＡＷＳ）
Claims (4)
- 仮想メモリ・コンピュータ・システムにおいてプロセスの実際ワーキング・セットを決定するシステムであって、
一貫性のある複数のベンチマークの実行を通して、動的に割り当てられたトランザクションおよび仮想メモリのページ・フォールトに関する情報を記録するように構成されており、時間順に配列されタイプスタンプを付されたページ・フォールトのリストおよび時間順に配列されタイプスタンプを付されたページ・トランザクションのリストをコンパイルする手段を含む、データ記録機構と、
前記データ記録機構に接続され、動的に割り当てられたメモリのブロックの各々を特定の高水準言語データ構造に関連付けるように構成されたデータ分析機構であって、前記ページ・フォールトのリストとページ・トランザクションのリストを関係付ける手段を含み、前記ページ・トランザクションと１組の規則とを比較することによって該ページ・トランザクションがデータ構造タイプと関連付けられ、前記規則の各々は前記データ構造タイプの１つについて一連の割り当てトランザクションおよび解放トランザクションを定義する、データ分析機構と、
割り当てトランザクションおよび解放トランザクションを識別するトランザクション処理手段と、
前記ページ・フォールトのリストとページ・トランザクションのリストを関係付け、ページ・フォールトと関連高水準データ構造の間の結合を形成するフォールト処理手段と、
を備える実際ワーキングセット決定システム。 - 仮想メモリ・コンピュータ・システムにおいてプロセスの実際ワーキング・セットを決定するシステムであって、
一貫性のある複数のベンチマークの実行を通して、動的に割り当てられたトランザクションおよび仮想メモリのページ・フォールトに関する情報を記録するように構成されたデータ記録機構と、
前記データ記録機構に接続され、動的に割り当てられたメモリのブロックの各々を特定の高水準言語データ構造に関連付けるように構成されており、前記高水準データ構造に、前記フォールトの各々を発生させたコード・プロシージャを関係付ける手段を含む、データ分析機構と、
を備える実際ワーキングセット決定システム。 - 仮想メモリ・コンピュータ・システムにおいてプロセスの実際ワーキング・セットを決定するシステムであって、
一貫性のある複数のベンチマークの実行を通して、動的に割り当てられたトランザクションおよび仮想メモリのページ・フォールトに関する情報を記録するように構成されたデータ記録機構と、
前記データ記録機構に接続され、動的に割り当てられたメモリのブロックの各々を特定の高水準言語データ構造に関連付けるように構成されたデータ分析機構と、を備え、
前記仮想メモリ・コンピュータ・システムはオペレーティング・システム・カーネルと物理メモリを含み、該オペレーティング・システム・カーネルはプロセスの１つの仮想ページだけを前記物理メモリに保持し、これによって、該１つの仮想ページ以外の仮想ページにアクセスが試みられる度にフォールトを発生させる、実際ワーキングセット決定システム。 - 仮想メモリ・コンピュータ・システムにおいてプロセスの実際ワーキング・セットを決定するシステムであって、
一貫性のある複数のベンチマークの実行を通して、動的に割り当てられたトランザクションおよび仮想メモリのページ・フォールトに関する情報を記録するように構成されたデータ記録機構と、
前記データ記録機構に接続され、動的に割り当てられたメモリのブロックの各々を特定の高水準言語データ構造に関連付けるように構成されており、１組の規則を対話型で管理する規則管理モジュールと規則を対話型で作成し編集する規則エディタとを含む、データ分析機構と、
を備える実際ワーキングセット決定システム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US380,166 | 1995-01-30 | ||
| US08/380,166 US5721917A (en) | 1995-01-30 | 1995-01-30 | System and method for determining a process's actual working set and relating same to high level data structures |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH08241250A JPH08241250A (ja) | 1996-09-17 |
| JP3772996B2 true JP3772996B2 (ja) | 2006-05-10 |
Family
ID=23500145
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP00650896A Expired - Fee Related JP3772996B2 (ja) | 1995-01-30 | 1996-01-18 | 実際ワーキング・セット決定システム |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5721917A (ja) |
| JP (1) | JP3772996B2 (ja) |
| DE (1) | DE19600428C2 (ja) |
| GB (1) | GB2297402B (ja) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6658648B1 (en) * | 1997-09-16 | 2003-12-02 | Microsoft Corporation | Method and system for controlling the improving of a program layout |
| US6381740B1 (en) * | 1997-09-16 | 2002-04-30 | Microsoft Corporation | Method and system for incrementally improving a program layout |
| US6158024A (en) * | 1998-03-31 | 2000-12-05 | International Business Machines Corporation | Method and apparatus for structured memory analysis of data processing systems and applications |
| FR2774788B1 (fr) * | 1998-02-12 | 2000-03-24 | Bull Sa | Procede de controle d'acces memoire sur une machine avec memoire a acces non uniforme et machine pour mettre en oeuvre ce procede |
| US6496912B1 (en) * | 1999-03-25 | 2002-12-17 | Microsoft Corporation | System, method, and software for memory management with intelligent trimming of pages of working sets |
| US6658653B1 (en) * | 2000-06-08 | 2003-12-02 | International Business Machines Corporation | Debugging methods for heap misuse |
| US20040015864A1 (en) * | 2001-06-05 | 2004-01-22 | Boucher Michael L. | Method and system for testing memory operations of computer program |
| GB2423781B (en) | 2003-03-19 | 2007-03-28 | Varco Int | Apparatus and method for moving drilled cuttings |
| GB0505289D0 (en) * | 2005-03-15 | 2005-04-20 | Symbian Software Ltd | Computing device with automated page based rem shadowing and method of operation |
| GB0515395D0 (en) * | 2005-07-27 | 2005-08-31 | Ibm | A method or apparatus for determining the memory usage of a program |
| GB0523115D0 (en) * | 2005-11-12 | 2005-12-21 | Ibm | A resource optimisation component |
| KR100772863B1 (ko) * | 2006-01-13 | 2007-11-02 | 삼성전자주식회사 | 요구 페이징 기법을 적용한 시스템에서 페이지 교체 수행시간을 단축시키는 방법 및 장치 |
| US8037039B2 (en) * | 2007-04-20 | 2011-10-11 | Microsoft Corporation | Runtime class database operation |
| US8473691B2 (en) * | 2009-02-27 | 2013-06-25 | Ryosuke Ohgishi | Memory management device, image forming apparatus, and image forming method |
| US8103849B2 (en) | 2009-04-24 | 2012-01-24 | International Business Machines Corporation | Reducing memory usage of kernel memory management structures |
| JP6099458B2 (ja) | 2013-03-29 | 2017-03-22 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | 特定の仮想マシンに関連するトレース・データを得るためのコンピュータ実装方法、プログラム、トレーサ・ノード |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4758944A (en) * | 1984-08-24 | 1988-07-19 | Texas Instruments Incorporated | Method for managing virtual memory to separate active and stable memory blocks |
| US4761737A (en) * | 1986-01-16 | 1988-08-02 | International Business Machines Corporation | Method to automatically increase the segment size of unix files in a page segmented virtual memory data processing system |
| US4730249A (en) * | 1986-01-16 | 1988-03-08 | International Business Machines Corporation | Method to operate on large segments of data in a virtual memory data processing system |
| US4989134A (en) * | 1987-03-20 | 1991-01-29 | Hewlett-Packard Company | Method and apparatus for enhancing data storage efficiency |
| US5055999A (en) * | 1987-12-22 | 1991-10-08 | Kendall Square Research Corporation | Multiprocessor digital data processing system |
| CA1329432C (en) * | 1988-11-02 | 1994-05-10 | William Davy | Method of memory and cpu time allocation for a multi-user computer system |
| US5101485B1 (en) * | 1989-06-29 | 1996-12-10 | Frank L Perazzoli Jr | Virtual memory page table paging apparatus and method |
| US5086386A (en) * | 1990-03-23 | 1992-02-04 | Sun Microsystems, Inc. | Method and apparatus for benchmarking the working set of window-based computer systems |
| US5247687A (en) * | 1990-08-31 | 1993-09-21 | International Business Machines Corp. | Method and apparatus for determining and using program paging characteristics to optimize system productive cpu time |
| US5237673A (en) * | 1991-03-20 | 1993-08-17 | Digital Equipment Corporation | Memory management method for coupled memory multiprocessor systems |
| US5263032A (en) * | 1991-06-27 | 1993-11-16 | Digital Equipment Corporation | Computer system operation with corrected read data function |
-
1995
- 1995-01-30 US US08/380,166 patent/US5721917A/en not_active Expired - Lifetime
-
1996
- 1996-01-03 GB GB9600053A patent/GB2297402B/en not_active Expired - Fee Related
- 1996-01-08 DE DE19600428A patent/DE19600428C2/de not_active Expired - Fee Related
- 1996-01-18 JP JP00650896A patent/JP3772996B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| GB2297402B (en) | 1999-09-22 |
| DE19600428C2 (de) | 2000-08-03 |
| JPH08241250A (ja) | 1996-09-17 |
| GB9600053D0 (en) | 1996-03-06 |
| GB2297402A (en) | 1996-07-31 |
| US5721917A (en) | 1998-02-24 |
| DE19600428A1 (de) | 1996-08-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3772996B2 (ja) | 実際ワーキング・セット決定システム | |
| US9858183B2 (en) | Determining a benefit of reducing memory footprint of a Java application | |
| US6795836B2 (en) | Accurately determining an object's lifetime | |
| US6694507B2 (en) | Method and apparatus for analyzing performance of object oriented programming code | |
| US7325234B2 (en) | System and method for monitoring computer application and resource utilization | |
| US8336033B2 (en) | Method and system for generating a hierarchical tree representing stack traces | |
| EP1172729B1 (en) | Apparatus and method for cataloguing symbolic data for use in performance analysis of computer programs | |
| US7178145B2 (en) | Queues for soft affinity code threads and hard affinity code threads for allocation of processors to execute the threads in a multi-processor system | |
| US8566810B2 (en) | Using database knowledge to optimize a computer program | |
| US7500077B2 (en) | Use of region-oriented memory profiling to detect heap fragmentation and sparse memory utilization | |
| US7793304B2 (en) | System and method for monitoring memory usage | |
| US20020120428A1 (en) | Topological, on-the-fly classification of objects into a global set and local sets | |
| EP1260901A2 (en) | Method and apparatus for managing hashed objects | |
| US20080276252A1 (en) | Kernel event visualization | |
| US8478738B2 (en) | Object deallocation system and method | |
| US6609249B2 (en) | Determining maximum number of live registers by recording relevant events of the execution of a computer program | |
| US8272001B2 (en) | Management of resources based on association properties of association objects | |
| US20090228537A1 (en) | Object Allocation System and Method | |
| CN111400135A (zh) | 一种业务数据的提取方法及装置 | |
| Harvey-Lees-Green et al. | A Dynamic Memory Management Unit for Real Time Systems | |
| JPH0962493A (ja) | ソフトウェアインストールシステム | |
| EP1221085A2 (en) | Method and system for dynamic injection of execution logic into a windowed operating system | |
| US20090157742A1 (en) | On Demand Capture of Database Application Environmental Resources | |
| Kistler et al. | Automated record layout for dynamic data structures | |
| CN118069529A (zh) | 性能数据处理方法、装置、设备、介质及产品 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051220 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060207 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060208 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090224 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100224 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100224 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110224 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120224 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130224 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130224 Year of fee payment: 7 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130224 Year of fee payment: 7 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130224 Year of fee payment: 7 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130224 Year of fee payment: 7 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140224 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |