Per visualizzare l'articolo in inglese, selezionare la casella di controllo Inglese. È possibile anche visualizzare il testo inglese in una finestra popup posizionando il puntatore del mouse sopra il testo.
Traduzione
Inglese

ID notifica profilatura e runtime

E notifiche runtime forniscono un ID per le classi, i thread, i domini applicazione riportati e così via. Ali ID possono essere utilizzati per eseguire una query per ottenere ulteriori informazioni sul Language Runtime comune (CLR). Ogni ID è l'indirizzo di un blocco di memoria che descrive l'elemento. Tuttavia, gli ID devono essere trattati come handle opachi dai profiler. Se in una chiamata a una funzione di analisi viene utilizzato un ID non valido, i risultati saranno indefiniti. È probabile che il risultato sarà una violazione di accesso. Il profiler deve verificare che gli ID utilizzati siano validi. L'API di analisi non esegue alcun tipo di convalida, perché creerebbe un sovraccarico e potrebbe notevolmente rallentare l'esecuzione dell'applicazione.

Nelle sezioni seguenti vengono descritte le caratteristiche degli ID nell'API di analisi.

Un ProcessID è univoco in tutto il sistema per la durata del processo. Tutti gli altri ID sono univoci a livello di processo per la durata dell’ID.

Gli ID sono organizzati in una gerarchia che rispecchia la gerarchia nel processo. I processi contengono domini applicazione che contengono assembly che contengono moduli che contengono classi che contengono funzioni. I thread sono contenuti all'interno di processi e possono spostarsi da un dominio applicazione a un altro. Gli oggetti sono per lo più contenuti all'interno di domini applicazione e molto pochi oggetti possono essere contemporaneamente membri di più domini applicazione. I contesti sono contenuti all'interno di processi.

Quando un processo, dominio applicazione, assembly, thread o oggetto specificato viene eliminato in modo permanente, liberato, rilasciato o termina, l’ID associato diventerà non valido. Quando un ID specificato diventa non valido, diventeranno non validi anche tutti gli ID contenuti in esso. Ad esempio, quando un dominio applicazione viene scaricato, il relativo AppDomainID diviene non valido. AssemblyID , ModuleID, ClassID e FunctionID che corrispondono agli assembly, ai moduli, alle classi e alle funzioni all'interno del dominio applicazione diventeranno anch’essi non validi.

La durata e la stabilità degli ID specifici sono le seguenti:

Ogni dominio applicazione creato dall'utente in un processo ha un AppDomainID. Il dominio predefinito e uno speciale pseudodominio utilizzati per contenere assembly indipendenti dal dominio hanno anche un AppDomainIDs.

Assembly, moduli, classi, funzioni e handle di Garbage Collector hanno un'affinità del dominio applicazione. In altri termini, se un assembly viene caricato in più domini applicazione, l'assembly e tutti i suoi moduli, classi, funzioni e handle di Garbage Collector avranno un ID diverso in ogni dominio applicazione e le operazioni su ciascun ID saranno effettive soltanto nel dominio applicazione associato. Assembly indipendenti dal dominio sono visualizzati nello speciale pseudo dominio indicato in precedenza.

Tutti gli ID tranne ObjectID devono essere trattati come valori opachi. La maggior parte degli ID non necessita di ulteriori spiegazioni. I seguenti ID meritano una spiegazione più approfondita:

  • I ClassID rappresentano le classi. Nel caso di classi generiche, rappresentano tipi completamente dotati di istanze. Gli oggetti List<int>, List<char>, List<object> e List<string> dispongono ognuno del relativo oggetto ClassID. List<T> è un tipo privo di istanze e non dispone di un oggetto ClassID. Dictionary<string,V> è un tipo con istanze parziali e non dispone di un oggetto ClassID.

  • I FunctionID rappresentano il codice nativo per una funzione. Nel caso di funzioni generiche (o funzioni sulle classi generiche), possono esistere più creazioni di istanze del codice nativo e quindi più FunctionID per una funzione specificata. Le creazioni di istanze del codice nativo possono essere condivise tra tipi diversi (ad esempio, List<string> e List<object> condividono il codice), quindi un FunctionID può appartenere a più di un ClassID.

  • Gli ObjectID rappresentano oggetti sottoposti a procedure di Garbage Collection. Un ObjectID è l'indirizzo corrente di un oggetto quando il profiler riceve l’ObjectID e può esser diverso in ogni Garbage Collection. Di conseguenza, un valore di ObjectID è valido solo tra il momento in cui viene ricevuto e il momento in cui inizia l’operazione successiva di Garbage Collection. CLR fornisce anche notifiche per consentire a un profiler di aggiornare le mappe interne di rilevamento degli oggetti, in modo tale da poter gestire un ObjectID valido in diverse operazioni di Garbage Collection.

  • I valori GCHandleID rappresentano le voci nella tabella degli handle di Garbage Collection. I valori GCHandleID, a differenza di ObjectID, sono valori opachi. Gli handle della Garbage Collection sono in alcuni casi creati dallo stesso CLR o possono essere creati utilizzando la struttura GCHandle. (Si noti che la struttura GCHandle rappresenta solo l’handle, che non è contenuto nella struttura.)

  • I ThreadID rappresentano i thread gestiti. Se un host supporta l’esecuzione in modalità fiber, un thread gestito può esistere su diversi thread del sistema operativo, a seconda del momento in cui viene esaminato.

    Nota Nota

    L'analisi delle applicazioni in modalità fiber non è supportata in .NET Framework versione 2.0.

Mostra: