Compartilhar via


Profiling e identificações de notificação de tempo de execução

Notificações de tempo de execução fornecem uma ID para classes relatadas, segmentos, domínios de aplicativo e assim por diante. Essas IDs podem ser usadas para consultar o common linguagem tempo de execução (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 sistema autônomo alças opacas por criadores de perfis. Se uma ID inválido for usada em uma telefonar 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 deve garantir que as identificações que está sendo usadas sejam válidas. A API de criar de perfil não executa qualquer tipo de validação, porque o que criaria sobrecarga e seria lenta a execução do aplicativo consideravelmente.

Características de IDs de criação de perfil

As seções a seguir descrevem as características de 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 durante a tempo de vida da ID.

E contenção de hierarquia

As iDs são organizadas em uma hierarquia que espelhe a hierarquia do processo. Processos contêm 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 do aplicativo para o domínio do aplicativo. Objetos estão contidos na maioria das vezes nos domínios de aplicativo e uma muito poucos objetos podem ser membros de vários domínios do aplicativo ao mesmo time. Contextos estão contidos dentro de processos.

Tempo de vida e estabilidade

Quando um determinado processo, domínio do aplicativo, assembly, thread ou objeto é destruído, liberado ou liberado ou termina, a ID de associado a ele se torna inválido. Quando uma determinada ID for inválido, todas as identificações que ele contém também se tornar inválidas. Por exemplo, quando um domínio do aplicativo é descarregado, seus AppDomainID torna-se inválido. The AssemblyIDs, ModuleIDs, ClassIDs, e FunctionIDs correspondente a assemblies, módulos, classes e funções dentro do domínio do aplicativo também se tornar inválidos ao mesmo time.

A tempo de vida e a estabilidade do IDs específicos são:

Afinidade de domínios de aplicativo

Cada domínio do aplicativo criados pelo usuário em um processo possui um AppDomainID. O domínio padrão e um pseudo-domain especial usado para conter os assemblies domain-neutral também têm AppDomainIDs.

Assemblies, módulos, classes, funções e alças de coletor de lixo têm afinidade de domínio do aplicativo. Isso significa que se um assembly for carregado em vários domínios do aplicativo, o assembly e todos os seus módulos, classes, funções e alças de coletor de lixo terão uma identificação diferente em cada domínio do aplicativo e operações em cada ID entrarão em vigor somente no domínio do aplicativo associado. Assemblies domínio-neutral aparecem no pseudo-domínio especial mencionada anteriormente.

Observações especiais

Todas sistema autônomo identificações exceto ObjectID devem ser tratados sistema autônomo valores opacos. A maioria das identificações são bastante auto-explicativo. Os seguintes IDs são vale a pena explicar mais detalhadamente:

  • ClassIDs representam classes. No caso de classes genéricas, eles representam tipos totalmente instanciados. List<int>, List<char>, List<object>, e List<string> cada um tem suas próprias ClassID. List<T> é um tipo sem instância e não tenha ClassID. Dictionary<string,V> é um tipo instanciado parcialmente e não tenha ClassID.

  • FunctionIDs representam o código nativo para uma função. No caso de genéricos (ou funções em classes genéricas), código nativo várias instanciações e, portanto, vários FunctionIDs, talvez haja de 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. An ObjectID é o endereço corrente de um objeto no momento recebe o criador de perfil a ObjectIDe pode alterar com cada lixo coleção. Portanto, um ObjectID o valor é válido apenas entre o momento em que é recebida e a hora lixo próximo coleção é iniciado. O CLR também fornece notificações para um criador de perfil atualizar seus mapas de acompanhamento de objeto internos para que o criador de perfil pode manter um válido ObjectID entre coletas de lixo.

  • GCHandleIDs representam entradas coleção's lixo lidar com a tabela. GCHandleIDs, diferentemente ObjectIDs, são opacas valores. Alças de coleta de lixo são criadas pelo CLR em alguns casos, ou elas podem ser criadas usando o GCHandle estrutura. (Observe que o GCHandle estrutura representa somente o identificador; o identificador não está contido na estrutura.)

  • ThreadIDs representam gerenciado threads. Se um host oferece suporte a execução no modo fibra um gerenciado thread podem existir no sistema operacional diferente thread s, dependendo de quando ele é examinado.

    ObservaçãoObservação:

    P não tem suporte no rofiling dos aplicativos de modo de fibra o .NET estrutura v ersion 2.0 .

Consulte também

Outros recursos

Recursos comuns da API de criação de perfil

Visão geral de criação de perfil

Criação de perfil (referência de API não gerenciada)