(57)【特許請求の範囲】
【請求項１】
データ処理システムにおいて実行されるアプリケーションプログラムのパフォーマンスを解析する方法であって、
前記アプリケーションプログラムは、各スレッドが複数の状態を遷移する複数のスレッドを用いて実行され、
当該方法は、
測定期間中に各スレッドの複数の状態について前記アプリケーションプログラムの所定のパフォーマンスに関する特徴に対応するデータを読むステップと、
各スレッドについて、前記測定期間と、前記アプリケーションプログラムの所定のパフォーマンスに関する特徴に対応するパフォーマンスレベルと、各状態における各時点のパフォーマンスの変化とを反映したグラフを有する画像を表示するステップと、
を有する方法。
【請求項２】
アプリケーションプログラムのパフォーマンスを解析する装置であって、
測定期間中に各スレッドの複数の状態について前記アプリケーションプログラムの所定のパフォーマンスに関する特徴に対応するデータを読み、各スレッドについて、前記測定期間と、前記アプリケーションプログラムの所定のパフォーマンスに関する特徴に対応するパフォーマンスレベルと、各状態における各時点のパフォーマンスの変化とを反映したグラフを有する画像を表示するプログラムを有するメモリと、
前記プログラムを実行するプロセッサと、
を有する装置。
【請求項３】
プロセッサを実行させる方法を実行するようコンピュータシステムを制御するための命令を有するコンピュータ可読媒体であって、
前記方法は、
測定期間中に各スレッドの複数の状態について前記アプリケーションプログラムの所定のパフォーマンスに関する特徴に対応するデータを読むステップと、
各スレッドについて、前記測定期間と、前記アプリケーションプログラムの所定のパフォーマンスに関する特徴に対応するパフォーマンスレベルと、各状態における各時点のパフォーマンスの変化とを反映したグラフを有する画像を表示するステップと、
を有するコンピュータ可読媒体。
【請求項４】
データ処理システムにおいて実行されるアプリケーションプログラムのパフォーマンスを解析する方法であって、
前記アプリケーションプログラムは、各スレッドが複数の状態を遷移する複数のスレッドを用いて実行され、
当該方法は、
測定期間中に各スレッドの複数の状態について前記アプリケーションプログラムの所定のパフォーマンスに関する特徴に対応するデータを読むステップと、
各スレッドについて、前記測定期間と、前記アプリケーションプログラムの所定のパフォーマンスに関する特徴に対応するパフォーマンスレベルとを反映したグラフを有する画像を表示するステップと、
前記アプリケーションプログラムのパフォーマンスを向上させるよう調整されるべき前記アプリケーションプログラムの何れかの部分をユーザに指示するステップと、
を有する方法。
【請求項５】
前記グラフは、前記スレッド間における処理の同期を向上させるよう調整されるべき前記アプリケーションプログラムの何れかの部分をユーザに指示する、請求項４記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パフォーマンス解析に関し、更に詳しくは、アプリケーションプログラムのパフォーマンスデータの多要素閲覧画面を提供する方法に関する。
【背景技術】
【０００２】
マルチスレッドは、アプリケーションプログラムを論理的に独立した制御「スレッド」に区分けするものであり、並列実行が可能である。各スレッドは、命令シーケンスとその命令により使用されるデータを含み、特定のプログラムタスク、例えば、演算、入出力機能等を実行する。マルチプロセッサ方式のデータプロセッシングシステム、即ち、マルチプロセッサコンピュータシステムを用いる場合には、各プロセッサは、プロセッサの数に応じて１又は複数のスレッドを実行することにより、当該プログラムのマルチプロセッシングを実現する。
【０００３】
プログラムは、マルチスレッド化が可能であるが、これは、単一プロセッサが全スレッドを実行するのに使用された場合である。単一プロセッサが一度にただ一つの命令を実行する場合には、プロセッサは、マルチスレッドを並列に実行、例えば、次のように実行する：あるスレッドに対応する命令を実行し、これを選択された命令に到達するまで実行し、そしてそのスレッドの命令を停止し、別のスレッドに対応する命令を実行し、これらを全スレッドについて完了するまで行う。このような概略で、プロセッサが所定時間内に複数の命令の実行を開始する限り、スレッドはその所定時間内において「走行中」と称される。
【０００４】
マルチプロセッサコンピュータシステムは、通常、複雑な演算問題を解くためのアプリケーションプログラムを実行するのに使用され、種々の主要問題は、種々のプロセッサ上で並行実行されているプログラムの一部を使用して解くことができる。プログラムを実行するために、このようなシステムを使用するのは、高いパフォーマンスを実現するためであり、特に、演算リソースの浪費を除去するパフォーマンスのレベルを高くするためである。コンピュータリソースを浪費する場合として、例えば、プロセッサがアイドル状態（即ち、プログラム命令を実行していない場合）にあるときが挙げられ、アイドル状態にあると、その時間分浪費することになる。このような待ちサイクルは、一方のプロセッサが実行する命令が、他方のプロセッサにより実行される命令セットの結果を必要とすることによる結果である。
【０００５】
従って、このようなデータプロセッシングシステム上で実行されるプログラムのパフォーマンスを解析し、最適パフォーマンスが実現されたか否かを判断することが必要となる。最適パフォーマンスが実現されない場合には、改善用のエリアを確認することが必要である。
【０００６】
この点については、パフォーマンス解析は、通常、３つのエリアの情報収集を必要とする。まず、第一に、プログラム実行中の所定時間におけるプロセッサ状態が挙げられる。プロセッサ状態は、当該プロセッサが特定の時間間隔で実行するプログラム（例えば、サブプログラム、ループ、又は他のコードブロック等の命令セット）の一部に着目したものである。第二に、プロセッサが、ある状態から他の状態へ遷移するのに費やす時間がどの位かということが挙げられる。第三に、プロセッサがそのピークパフォーマンス時にどのようにして実行を停止するのかということが挙げられる。しかしながら、これらの３つのエリアでは、完全な解析はできない。パフォーマンス解析における４つめのコンポーネント、即ち、特定状態においてプロセッサが何をしたか（例えば、演算、データ入力、データ出力）という情報を提供しないからである。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特定状態の間、プロセッサが何をしたかを考察する場合には、パフォーマンス解析ツールは、当該パフォーマンスレベルでの状態におけるオペレーションの影響を決定することができる。これらの要因が一旦確認されると、パフォーマンスに対して重要なインパクトを与えるオペレーションと、それよりは重要度が低いインパクトを与えるオペレーションとを同調させることができ、全体としてよりよいパフォーマンスレベルを実現することができる。例えば、第一のスレッドは、重要なリソースを使用するオペレーションを実行することができるが、その間、第一のスレッドと並列に別個のオペレーションを実行するようにスケジューリングされた他のスレッドは、当該第一のスレッドがそのオペレーションを完遂するまでアイドル状態である。従って、第二のスレッドには、第一のスレッドのオペレーションの完遂を要求しない他のオペレーションを実行させ、これによって、当該第二のスレッドのアイドル状態を除去することが望ましい。
【０００８】
パフォーマンス解析ツールが特定状態で発生した問題を通知するが、当該問題をアプリケーションで発生した他のイベントに関連させるのに失敗したとき（例えば、他の状態のオペレーション）は、当該通知された情報は、どちらかといえば無意味なものとなる。有用なものとするには、パフォーマンス解析ツールは、パフォーマンス情報がプログラム実行にどのように関連しているのかをディベロッパーが決定するのを補助する必要がある。従って、発生したパフォーマンス問題の内容をディベロッパーが判断できるようにすれば、問題分析に役立つものとなる。
【０００９】
パフォーマンス解析用にこの情報を収集するプロセスは、「インストルメンテーション」と称される。インストルメンテーションは、通常、検査中のプログラムに命令追加を要求するものであり、これにより、当該プログラムが実行されたときに当該命令によりデータが生成され、このデータからパフォーマンス情報が取り出すことができる。
【００１０】
カレントパフォーマンス解析ツールがデータを収集する方法には、サブプログラムレベルインストルメンテーションとバケットレベルインストルメンテーションという２つの方法があり、いずれを用いてもよい。パフォーマンス解析のサブプログラムレベルインストルメンテーション方法は、各サブプログラムの呼出を反映するデータ生成用の命令セットを用いて、当該サブプログラムを操作（インストルメント）することによって多くのサブプログラムの呼出を検出する。この方法によれば、ディベロッパーは、各サブプログラムにより、又は当該サブプログラムの特定部分により実行されたオペレーション（例えば、サブプログラム内の開始・終了ポイント収集データの指定により実行されたオペレーション）のパフォーマンスデータを検出することができない。
【００１１】
バケットレベルのインストルメンテーションのパフォーマンス解析ツールは、実行コードを等間隔に配置されたグループ又はバケットに分割する。パフォーマンスデータは、指定された時間間隔でプログラムカウンタが特定バケット内にあった回数を検出する。このパフォーマンスデータ収集方法は、実質的に、指定された時間間隔でプログラムカウンタのスナップショットをとる。この方法では、包括的なパフォーマンス情報を提供することができない。その理由は、この方法は、指定された時間間隔での特定バケットのデータ収集に留まるからである。
【００１２】
また、現在のパフォーマンス解析方法によれば、パフォーマンスデータをカスタマイズして収集又は出力を行うことができない。一般に、パフォーマンスツールは、予め指定されたディベロッパー呈示用のデータセットのみを収集する。
【００１３】
本発明は、上述した従来の欠点を克服するためになされたものであり、データプロセッシングシステムにおいて実行されるマルチスレッド化プログラムのパフォーマンス解析を容易にすることができるアプリケーションプログラムのパフォーマンス解析方法、アプリケーションプログラムのパフォーマンス解析に用いられるシステム及び装置を提供することを課題とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するために、本発明に係る方法、システム及び装置は、測定期間内に実行される各スレッドの状態を反映するデータを受信し、前記測定期間内の各スレッド状態に対応するパフォーマンスレベルを表示することにより、データプロセッシングシステムで実行されるスレッドのパフォーマンスを解析することを要旨とするものである。
【発明の効果】
【００１５】
本発明に係る請求項１乃至３に記載のパフォーマンス解析方法は、測定期間内に実行される各スレッドの状態を反映し収集すべきものと指定されたデータを受信し、プログラム実行中に生成されたデータファイルにアクセスして当該測定期間内の各スレッド状態に対応するパフォーマンスレベルを表示するものであるから、ディベロッパーは、どのようにパフォーマンスデータがプログラムの各スレッドに関連しているかを判断することができるとともに、プログラム内で生じたパフォーマンス発行の理解や、その順次診断が簡単になる。従って、本発明によれば、パフォーマンス解析を容易に行うことができるという利点がある。
【図面の簡単な説明】
【００１６】
【図１】本発明に係るパフォーマンス解析システムを実装するのに好適なデータプロセッシングシステムを示した図である。
【図２】本発明に係る方法、システム及び装置の一実施形態に係るパフォーマンス解析システムのブロック構成を示した図である。
【図３】本発明の一実施形態に係るパフォーマンス解析システムにより実行されるオペレーションを説明したフローチャートである。
【図４】本発明の一実施形態に係り、アプリケーションプログラムのパフォーマンスデータの多要素ディスプレイを示した図である。
【発明を実施するための形態】
【００１７】
以下、添付図面を参照して本発明の一実施の形態を説明する。また、この説明によって本発明によって得られる利点と趣旨とを裏付けようとするものである。尚、図面及び説明において同一又は略同一の部材を参照する場合には、できる限り同一の参照符号を用いている。
概略
本発明に係る方法、システム及び装置は、アプリケーションプログラムの実行中に収集されたパフォーマンスデータを利用して、プログラムのパフォーマンスデータをディベロッパーに対して図式的に説明しようとするものである。プログラムは、実行中にパフォーマンスデータを生成するように操作（インストルメント）される。各プログラムスレッドは、１又は複数のオペレーションを実行するものであり、各オペレーションは、種々のスレッドの状態を反映する。パフォーマンスデータは、実行中のスレッドの各状態のパフォーマンスレベルと同様に、各スレッドの全パフォーマンスを反映するものであればよい。ディベロッパーは、収集すべきパフォーマンスデータのタイプと範囲とを指定することができる。全スレッドのパフォーマンスを同時にグラフィック表示すれば、ディベロッパーは、スレッド間のオペレーションを同期させることにより、全パフォーマンスを改善するために何時どこで適切な調整を行うべきかが判る。
【００１８】
パフォーマンス解析データベースへのアクセス言語は、本発明に係る方法でプログラムを操作（インストルメント）するために使用される。この操作（インストルメント）は、プログラム内の指定ロケーションに命令を追加する周知の技術を用いて自動的に、又はディベロッパーによる手動操作で行うことができる。命令は、マルチシステムコンポーネントからのパフォーマンスデータの収集を指定するものであればよく、パフォーマンスデータは、ハードウエア及びオペレーティングシステムの両者から収集可能であればよい。
【００１９】
パフォーマンスデータの４要素ディスプレイは、スレッド情報、時間、状態及びパフォーマンスレベルを含むものである。パフォーマンスアナライザは、また、ディベロッパーによって指定されたパフォーマンス測定法により数式評価を行い、その演算結果を表示する。
パフォーマンス解析システム
図１は、本発明に係る方法及びシステムの実施に好適なデータプロセッシングシステム１００を示したものである。データプロセッシングシステム１００は、コンピュータシステム１０５を備え、このコンピュータシステム１０５は、ローカルエリアネットワーク、ワイドエリアネットワーク又はインターネット等のネットワーク１９０に接続されている。
【００２０】
コンピュータシステム１０５は、メインメモリ１３０、補助記憶デバイス１４０、プロセッサ１５０、入力デバイス１７０及びビデオディスプレイ１６０を備える。これらの内部コンポーネントは、システムバス１６５を経由して互いに情報交換を行う。当該コンポーネントは、本発明に係る方法を実施したり、本発明に係るシステムを構成するのに好適な殆どのコンピュータシステムにおいて標準となっているものである。このようなコンピュータシステムとして、サンマイクロシステムズ・インコーポレーテッド製のSPARCstationが一例として挙げられる。
【００２１】
コンピュータシステム１００は、単一プロセッサを備えたものであるが、マルチプロセッサ環境においても同様に本発明に係る方法でオペレーションを実行できることは、いわゆる当業者にとっては周知である。
【００２２】
メモリ１３０は、プログラム１１０及びパフォーマンスアナライザ１１５を備えている。プログラム１１０は、マルチスレッド化プログラムである。本発明に係る方法においては、プログラム１１０のパフォーマンス解析を容易にする目的で、当該プログラムは、ディベロッパーが選択した適当な命令で操作（インストルメント）され、所定のパフォーマンスデータを生成する。
【００２３】
パフォーマンスアナライザ１１５は、２つのコンポーネントから構成されている。第一のコンポーネント１１５ａは、操作（インストルメント）されたプログラムにより指定された方法で実行される関数ライブラリである。第二のコンポーネント１１５ｂは、ディベロッパーインタフェースであり、２つの機能、即ち、（１）プログラムを自動的に操作（インストルメント）する機能、及び（２）プログラム実行時に収集されたパフォーマンス情報を閲覧する機能を実現するために用いられる。
【００２４】
説明したように、操作（インストルメンテーション）は、パフォーマンス解析インタフェース１１５ｂを用いて自動的に行うことができる。このようなアプローチによれば、ディベロッパーは、収集されるべきパフォーマンスデータのタイプをアナライザ用に指定し、アナライザは、パフォーマンス解析データベースアクセス言語による適当なコマンドをプログラムの適当な位置に追加する。このような手法での自動操作（インストルメンテーション）の技術は、いわゆる当業者にとっては周知である。これに代えて、実行中に指定パフォーマンスデータを記録できるように、ディベロッパーは、パフォーマンス解析データベースアクセス言語のコマンドを手動で適当な位置に挿入してもよい。プログラム１１０の実行中に生成されたパフォーマンスデータは、例えば、メインメモリ１３０等のメモリへ記憶される。
【００２５】
パフォーマンス解析インタフェース１１５ｂは、ディベロッパーにプログラム１１０の実行時に記憶されたパフォーマンスデータに対応するパフォーマンス情報の閲覧を許可する。後述するように、ディベロッパーは、閲覧画面を変更するのにアナライザと対話型で作業をすすめるが、これは、種々のコンフィギュレーションにおけるパフォーマンス情報を表示することにより、プログラムパフォーマンスを種々の視点で観察するためである。従って、プログラムが完全に最初から操作（インストルメント）されていると仮定すれば、各閲覧画面に対応する情報収集プログラムを繰り返し実行する必要はない。各閲覧画面は、（１）１又は複数のスレッドに用いる完全な測定サイクル、（２）各スレッドが各状態に出たり入ったりするタイミング、（３）各状態に対応する選択されたパフォーマンス基準、を表示する。
【００２６】
図１には示していないが、全てのコンピュータシステムと同様に、システム１０５は、オペレーティングシステムを備え、オペレーティングシステム１０５は、そのオペレーションを制御するが、この制御には、プロセッサ１５０によるプログラム１１０の実行が含まれる。また、本発明に係る好適な一実施形態の要旨は、メインメモリ１２０に記憶されたパフォーマンスアナライザとして開示されているが、いわゆる当業者にとっては、本発明に係るシステム及び方法の全てが、他のコンピュータ読取可能媒体（例えば、補助記憶装置（ハードディスク、フロッピーディスク、ＣＤ−ＲＯＭ等））、インターネットからの伝送波、又は、他の形態（リードオンリメモリ又はランダムアクセスメモリ）上に記憶され、又は、これらから読み出され得るものであることは自明である。以上、データプロセッシングシステム１００の指定コンポーネントについて説明したが、いわゆる当業者にとって周知のように実施形態として好適なデータプロセッシングシステムは、追加の又は異なるコンポーネントを備えたものでもよい。
【００２７】
図２は、本発明に係るパフォーマンス解析システムのブロック構成を示したものである。図示したように、プログラム２１０は、マルチスレッド２１２，２１４，２１６，２１８からなる。プロセッサ２２０は、スレッド２１２，２１４，２１６，２１８を並列に実行する。メモリ２４０は、共有メモリを表したものであり、この共有メモリは、全実行スレッドがアクセスすることができる。共有メモリへのアクセスを調整するプロトコルについては、シャウン・デニーによる米国特許出願第 号、発明の名称「共有メモリ分布の調整プロトコル」（代理人整理番号06502-0207-00000）に開示されており、これを参照されたい。ここでは、単一プロセッサ２２０が示されているが、マルチプロセッサを用いてスレッド２１２，２１４，２１６，２１８を実行してもよい。
【００２８】
マルチスレッド２１２，２１４，２１６，２１８の並列実行を容易にするために、オペレーティングシステムは、各スレッドのオペレーション用にメモリ２４０をセグメントに分割し、各セグメントフィールドを初期化する。例えば、メモリセグメント２４５は、エンター状態／イグジット状態の識別子、ディベロッパー指定情報、及びスレッド識別情報から構成される。エンター状態識別子は、実行中において、スレッドが特定状態に入った場合に、これに対応するデータを記憶する。同様に、イグジット状態識別子は、アプリケーションプログラムの実行中において、スレッドが特定状態から出た場合に、これに対応するデータを記憶する。ディベロッパー指定データは、収集されたパフォーマンス解析データを表している。
【００２９】
メモリのリザーブエリア２５０は、メモリ管理機能、例えば、競合スレッドの共有メモリ分布の調整等を行う。メモリのリザーブエリア２５０は、また、識別情報をメモリを使用するスレッドに割り付けるのに用いられる。
【００３０】
図３に示したフローチャートは、本発明の一実施形態に係るパフォーマンス解析システムのオペレーションに関する付加詳細情報を提供するものである。パフォーマンスデータを生成する命令は、プログラムに挿入される（ステップ３０５）。操作（インストルメント）されたプログラムが実行されると、パフォーマンスデータが生成される（ステップ３１０及び３１５）。パフォーマンスデータの閲覧要求があると、パフォーマンスアナライザは、パフォーマンスデータにアクセスし、これを表示する（ステップ３２０）。
【００３１】
パフォーマンスアナライザは、データに対応して、パフォーマンスデータ及び関連ソースコード・アセンブリコード（即ち、機械語命令）を表示することができる。これにより、ディベロッパーは、パフォーマンスデータを当該データを生成したソースコード及びアセンブリコードに関連付けることができる。
【００３２】
図４は、Ａ及びＢとラベルされた２つの部分を備えたディスプレイ４００を示したものである。Ａとラベルされた第一の部分は、スレッド、時間、状態、及びパフォーマンスという４つの要素でのアプリケーションプログラムのパフォーマンス特性を示したものである。各スレッドについてのパフォーマンス情報は、棒グラフタイプの様式を用いて水平に表示される。時間は、横軸に表示され、パフォーマンスは、縦軸に表示される。
【００３３】
ディスプレイ４００上の２つのスレッド、即ち、スレッド１及びスレッド２は、同時に実行される。図示されるように、スレッド１についての横軸は、４０２とラベルされている。スレッド１は、横軸４０２上の「ｘ」とラベルされた時間上のポイントで実行を開始する。スレッド２についての横軸は、４０４とラベルされている。スレッド２は、時間「ｂ」で実行を開始する。各スレッドは、マルチ状態でオペレーションを実行し、各状態は、異なるパターンで表される。スレッド２は、測定周期の開始点では、アイドル状態である。このようなアイドル状態をとる理由の一つとして、スレッド２がスレッド１からのリソースを待つ状態にあることが挙げられる。この情報に基づいて、ディベロッパーは、状態間にあるスレッドにオペレーションを割り当てることができる。この割当は、パフォーマンスを改善するために、例えば、同一のシステムリソースの同時使用を要求するオペレーションを実行することなくなされる。
【００３４】
図示されるように、スレッド１は、横軸４０２の時間「ｘ」のポイントで、状態４１０になり、その状態４１０を時間「ｙ」まで維持し、時間「ｍ」で状態４２０になり、その状態４２０を時間「ｎ」まで維持する。「ｘ」と「ｙ」との間の水平距離は、「ｍ」と「ｎ」との間の水平距離よりも短い。従って、スレッド１は、状態４２０でオペレーションが実行された時間の方が状態４１０でオペレーションが実行された時間よりも長くなっている。棒の垂直高さは、パフォーマンスレベルを示している。状態４１０の垂直高さは、状態４２０の垂直高さよりも低くなっており、これにより、状態４１０と状態４２０とは、異なったパフォーマンスレベルでオペレーションが実行されていることがわかる。実行スレッドがある状態から他の状態へ遷移するにつれての垂直高さの変化は、パフォーマンスレベルの変化に対応している。この情報は、パフォーマンスの連続状態間の遷移の影響を識別するのに用いることができる。更に、この情報によりディベロッパーの注意をプログラムエリアに差し向けることができ、パフォーマンス増加という変化を起こさせることが可能となる。
【００３５】
Ｂとラベルされたディスプレイの下半分は、パフォーマンスアナライザのインタフェースの評価形態を表したものである。ディベロッパーは、選択された状態のパフォーマンス測定法に対応した演算式を指定する。パフォーマンスアナライザは、収集されたパフォーマンスデータ用の式の値を演算する。
【００３６】
図示される例によれば、ディベロッパーは、状態４４０を選択している。最初の式「NUM_OPS/(100000*TIME)」は、一秒（MFLOPS）当たりの浮動小数点命令の回数（１００万の単位）を演算するためのものである。２番目の式「2*_CPU_MHZ」は、指定した状態のパフォーマンスの理論ピークレベルを演算するためのものである。パフォーマンスアナライザは、特定状態についての数量的情報を提供することに関して、これらの２つの式を評価するものであればよい。例えば、MFLOPSを状態４４０の理論ピークパフォーマンスレベルで除算することにより、パフォーマンスアナライザは、状態４４０における各オペレーションにより表された理論ピークのパーセンテージ計算してディベロッパーに呈示する。
結論
本発明に係る方法及びシステムは、ハードウエア及びアプリケーションプログラムのソフトウエアコンポーネントからパフォーマンスデータを収集し、これによって、ディベロッパーは、どのようにパフォーマンスデータがプログラムの各スレッドに関連しているかを理解することができる。更に、このようなパフォーマンスデータの収集は、結局のところ、ディベロッパーがプログラム内で生じたパフォーマンス発行を理解したり、順次診断したりするのを補助することになる。
【００３７】
以上本発明の実施の形態について説明したが、本発明の趣旨と範囲を逸脱しない範囲で種々の変更が可能であることは、いわゆる当業者にとって自明である。本発明の範囲は、特許請求の範囲とそれを裏付ける記述によって定められる。  以下、図面に基づいて本発明の実施の形態を説明する。
【符号の説明】
【００３８】
１００  データプロセッシングシステム
１０５  コンピュータシステム
１１０  プログラム
１１５，２３０  パフォーマンスアナライザ
１１５ａ  パフォーマンス解析ライブラリ
１１５ｂ  パフォーマンス解析インタフェース
１３０  メモリ
１４０  補助記憶デバイス
１５０，２２０  プロセッサ
１６０  ビデオディスプレイ
１６５  システムバス
１７０  入力デバイス
１８０  ネットワーク
２１０  プログラム
２１２，２１４，２１６，２１８  スレッド
２４０  メモリ
２５０  リザーブエリア
２４５  メモリセグメント
２６０  ディスプレイ
【図１】
0005432973.tif 000002
【図２】
0005432973.tif 000003
【図３】
0005432973.tif 000004
【図４】
0005432973.tif 000005