Criação de perfil e IDs de notificação de tempo de execução
Notificações de runtime fornecem uma ID para classes relatadas, segmentos, domínios de aplicativo e assim por diante. Essas IDs podem ser usados para consultar o common language runtime (CLR) para obter mais informações. Cada ID é o endereço de um bloco de memória que descreve o item. No entanto, IDs devem ser tratados como alças opacas por criadores de perfis. Se uma ID inválida é usada em uma chamada para uma função de criação de perfil, os resultados são indefinidos. Provavelmente, o resultado será uma violação de acesso. O criador de perfil possui que garantir que as identificações sendo usadas são válidas. A API de criação de perfil não executa qualquer tipo de validação, porque o que criaria sobrecarga e seria a execução do aplicativo bem mais lento.
As seções a seguir descrevem as características dos IDs na API de criação de perfil.
Unicidade
A ProcessID é exclusivo em todo o sistema para o tempo de vida do processo. Todas as outras identificações são todo o processo exclusivo para o tempo de vida da ID.
Hierarquia e a contenção
IDs são organizadas em uma hierarquia que espelhe a hierarquia no processo. Processos contêm os domínios de aplicativo, que contêm assemblies, que contêm módulos, que contêm classes, que contêm funções. Segmentos estão contidos dentro de processos e podem mover do domínio de aplicativo para o domínio de aplicativo. Na maioria das vezes, objetos estão contidos dentro de domínios de aplicativo e um pouquíssimos objetos podem ser membros de vários domínios de aplicativo ao mesmo tempo. Contextos estão contidos dentro de processos.
Tempo de vida e estabilidade
Quando um determinado processo, o domínio de aplicativo, o assembly, o thread ou o objeto é destruído, liberado ou liberado ou termina, a ID que está associada a ele se torna inválida. Quando uma determinada ID se torna inválida, todas as identificações de que ele contém também se tornar inválidas. Por exemplo, quando um domínio de aplicativo é descarregado, seus AppDomainID se torna inválida. O AssemblyIDs, ModuleIDs, ClassIDs, e FunctionIDs correspondente aos assemblies, módulos, classes e funções dentro do domínio de aplicativo também se tornar inválida no mesmo tempo.
A vida útil e a estabilidade do IDs específicos são:
ProcessID: Alive e estável da chamada para o ICorProfilerCallback::Initialize método até o retorno da ICorProfilerCallback::Shutdown método.
AppDomainID: Alive e estável da chamada para o ICorProfilerCallback::AppDomainCreationFinished método até o retorno da ICorProfilerCallback::AppDomainShutdownStarted método.
AssemblyID, ModuleID, ClassID: Alive e estável da chamada para o LoadFinished método para a identificação de até o retorno da UnloadStarted método para a identificação.
FunctionID: Alive e estável da chamada para o ICorProfilerCallback::JITCompilationFinished ou ICorProfilerCallback::JITCachedFunctionSearchFinished método até a destruição de que o contém ClassID.
ThreadID: Alive e estável da chamada para o ICorProfilerCallback::ThreadCreated método até o retorno da ICorProfilerCallback::ThreadDestroyed método.
ObjectID: Iniciando o funcionamento com a chamada para o ICorProfilerCallback::ObjectAllocated método. Qualificado para alterar ou which com cada coleta de lixo.
GCHandleID: Funcionamento da chamada para o ICorProfilerCallback2::HandleCreated método até o retorno da ICorProfilerCallback2::HandleDestroyed método.
Além disso, qualquer identificação que retorna a partir de uma função de criação de perfil será ativa no momento em que ele é retornado.
Afinidade de domínios de aplicativo
Cada domínio de aplicativo criados pelo usuário em um processo possui um AppDomainID. O domínio padrão e um pseudo-domain especial que é usado para manter os assemblies domain-neutral também tem AppDomainIDs.
Assemblies, módulos, classes, funções e alças de coletor de lixo tenham afinidade de domínio de aplicativo. Isso significa que se um assembly for carregado em vários domínios de aplicativo, o assembly e todos os seus módulos, classes, funções e alças de coletor de lixo terá uma identificação diferente em cada domínio de aplicativo, e operações em cada ID entrará em vigor somente no domínio de aplicativo associado. Assemblies domain-neutral aparecem na pseudo-domain especial mencionada anteriormente.
Observações adicionais
Todas as identificações exceto ObjectID devem ser tratados como valores opaco. A maioria dos IDs serão auto-explicativa. As seguintes identificações valem explicando mais detalhadamente:
ClassIDs representam classes. No caso de classes genéricas, eles representam tipos totalmente instanciados. List<int>, List<char>, List<object>, and List<string> each have their own ClassID. List<T>é um tipo sem instância e não possui ClassID. Dictionary<string,V>é um tipo instanciado parcialmente e não possui ClassID.
FunctionIDs representam o código nativo para uma função. No caso de genéricos funções (ou funções de classes genéricas), código nativo de várias instanciações e, portanto, vários FunctionIDs, podem existir para uma determinada função. Instanciações de código nativo podem ser compartilhadas entre tipos diferentes (por exemplo, List<string> e List<object> compartilhar código), portanto, um FunctionID pode pertencer a mais de um ClassID.
ObjectIDs representam objetos de coleta de lixo. Um ObjectID é o endereço atual de um objeto no momento em que o profiler recebe o ObjectIDe podem ser alterados a cada coleta de lixo. Portanto, um ObjectID o valor é válido apenas entre a hora em que é recebida e a hora de início da coleção próxima do lixo. O CLR também fornece notificações para um gerador de perfil atualizar seus mapas de objeto de controle internos, para que o profiler pode manter um válido ObjectID em coleções de lixo.
GCHandleIDs representam entradas na tabela de alça da coleta de lixo. GCHandleIDs, ao contrário das ObjectIDs, são valores opaco. Alças de coleta de lixo são criadas pelo CLR em alguns casos, ou eles podem ser criados usando o GCHandle estrutura. (Observe que o GCHandle estrutura somente representa o identificador; o identificador não está contido na estrutura.)
ThreadIDsegmentos do s representam gerenciado. Se um host oferece suporte a execução no modo de fibra, um segmento gerenciado pode existir em segmentos de sistema operacional diferente, dependendo de quando ele é examinado.
Observação
Não há suporte para a criação de perfil de aplicativos do modo de fibra na.NET Framework versão 2.0.