プロファイリングとランタイム通知 ID
ランタイム通知では、報告されたクラス、スレッド、アプリケーション ドメインなどの ID が示されます。 これらの ID を使用すると、共通言語ランタイム (CLR: Common Language Runtime) に詳細情報を照会できます。 各 ID は、項目を説明するメモリ内のブロックのアドレスです。 ただし、プロファイラーでは、ID を非透過的なハンドルとして扱う必要があります。 プロファイル関数の呼び出しで無効な ID が使用されると、結果は未定義になります。 多くの場合は、結果としてアクセス違反が発生します。 プロファイラーは、使用されている ID が有効であることを確認する必要があります。 プロファイル API ではどのような種類の検証も実行されません。検証を実行するとオーバーヘッドが生じ、アプリケーションの実行速度が大幅に低下するためです。
以下のセクションでは、プロファイル API の ID の特性について説明します。
一意性
ProcessID は、プロセスの有効期間中、システム全体で一意です。 その他のすべての ID は、ID の有効期間中、プロセス全体で一意です。
階層構造とコンテインメント
ID は、プロセスの階層構造を反映した階層構造にまとめられています。 プロセスにはアプリケーション ドメインが含まれています。アプリケーション ドメインにはアセンブリが、アセンブリにはモジュールが含まれています。モジュールにはクラスが、クラスには関数が含まれています。 スレッドはプロセス内に含まれ、アプリケーション ドメイン間で移動できます。 オブジェクトは多くの場合アプリケーション ドメイン内に含まれています。同時に複数のアプリケーション ドメインのメンバーであるオブジェクトは、ごく少数です。 プロセスの中にコンテキストが含まれています。
有効期間と安定性
特定のプロセス、アプリケーション ドメイン、アセンブリ、スレッド、またはオブジェクトが破棄、除去、または解放されるか終了すると、それに関連付けられた ID は無効になります。 特定の ID が無効になると、その ID に含まれるすべての ID も無効になります。 たとえば、アプリケーション ドメインがアンロードされると、AppDomainID が無効になります。 アプリケーション ドメイン内のアセンブリ、モジュール、クラス、および関数に対応する AssemblyID、ModuleID、ClassID、および FunctionID も同時に無効になります。
特定の ID の有効期間と安定性は次のようになります。
ProcessID: 生きている安定した状態は、ICorProfilerCallback::Initialize メソッドの呼び出しから始まり、ICorProfilerCallback::Shutdown メソッドから戻るまで続きます。
AppDomainID: 生きている安定した状態は、ICorProfilerCallback::AppDomainCreationFinished メソッドの呼び出しから始まり、ICorProfilerCallback::AppDomainShutdownStarted メソッドから戻るまで続きます。
AssemblyID、ModuleID、ClassID: 生きている安定した状態は、ID の LoadFinished メソッドの呼び出しから始まり、ID の UnloadStarted メソッドから戻るまで続きます。
FunctionID: 生きている安定した状態は、ICorProfilerCallback::JITCompilationFinished または ICorProfilerCallback::JITCachedFunctionSearchFinished メソッドの呼び出しから始まり、含まれている ClassID が破棄されるまで続きます。
ThreadID: 生きている安定した状態は、ICorProfilerCallback::ThreadCreated メソッドの呼び出しから始まり、ICorProfilerCallback::ThreadDestroyed メソッドから戻るまで続きます。
ObjectID: 生きている状態は、ICorProfilerCallback::ObjectAllocated メソッドの呼び出しから始まります。 ガベージ コレクションごとに変更するか死んだ状態にできます。
GCHandleID: 生きている状態は、ICorProfilerCallback2::HandleCreated メソッドの呼び出しから始まり、ICorProfilerCallback2::HandleDestroyed メソッドから戻るまで続きます。
さらに、プロファイル関数から戻される任意の ID は、戻された時点で生きています。
アプリケーション ドメインのアフィニティ
ユーザーが作成した、プロセス内の各アプリケーション ドメインには AppDomainID があります。 既定のドメインと、ドメイン中立のアセンブリを保持するために使用される特別な擬似ドメインにも AppDomainID があります。
アセンブリ、モジュール、クラス、関数、およびガベージ コレクター ハンドルには、アプリケーション ドメインとのアフィニティがあります。 つまり、アセンブリを複数のアプリケーション ドメインに読み込むと、アセンブリとそのすべてのモジュール、クラス、関数、およびガベージ コレクター ハンドルはアプリケーション ドメインごとに異なる ID を持ち、各 ID に対する操作は関連付けられたアプリケーション ドメインでのみ有効になります。 ドメイン中立のアセンブリは、前に説明した特別な擬似ドメインに含まれます。
追加情報
ObjectID を除くすべての ID は、非透過値として扱う必要があります。 ほとんどの ID は自己記述的です。 いくつかの ID について詳しく説明します。
ClassID はクラスを表します。 ジェネリック クラスの場合は、完全にインスタンス化される型を表します。 List<int>、List<char>、List<object>、および List<string> には、それぞれ独自の ClassID があります。 List<T> はインスタンス化されない型であり、ClassID を持ちません。 Dictionary<string,V> は部分的にインスタンス化される型であり、ClassID を持ちません。
FunctionID は関数のネイティブ コードを表します。 ジェネリック関数 (ジェネリック クラスの関数) の場合、複数のネイティブ コード インスタンス化により、特定の関数に対して複数の FunctionID が存在する可能性があります。 ネイティブ コード インスタンス化は、異なる複数の型で共有できるため (たとえば、List<string> と List<object> の共有コード)、FunctionID が複数の ClassID に属する場合があります。
ObjectID はガベージ コレクトされたオブジェクトを表します。 ObjectID は、プロファイラーが ObjectID を受け取った時点におけるオブジェクトの現在のアドレスであり、ガベージ コレクションごとに変更できます。 したがって、ObjectID 値は、受け取った時点から次回ガベージ コレクションの開始までの間のみ有効です。 CLR には、プロファイラーに対する内部オブジェクト トラッキング マップの更新通知も用意されています。これによりプロファイラーは、複数のガベージ コレクションにわたって有効な ObjectID を維持できます。
GCHandleID は、ガベージ コレクションのハンドル テーブルのエントリを表します。 GCHandleID は、ObjectID と異なり、非透過の値です。 ガベージ コレクション ハンドルは CLR 自体によって作成される場合があります。または、GCHandle 構造体を使用して作成できます (GCHandle 構造体はハンドルのみを表すことに注意してください。ハンドルは構造体に含まれていません)。
ThreadID はマネージ スレッドを表します。 ホストがファイバー モードでの実行をサポートする場合は、いつ実行するのかに応じて、マネージ スレッドが別のオペレーティング システム スレッドに存在してもかまいません。
.gif "メモ")
メモファイバー モード アプリケーションのプロファイルは、.NET Framework Version 2.0 ではサポートされていません。