Objeto de inspeção na API de criação de perfil

Artigo
08/25/2010

Esta seção discute como usar métodos de criação de perfil para inspecionar os objetos.

FunctionEnter2 e FunctionLeave2 Callbacks

The FunctionEnter2 and FunctionLeave2 retornos de chamada fornecem informações sobre sistema autônomo argumentos e retornam o valor de uma função, sistema autônomo regiões de memória. Os argumentos são armazenados da esquerda para direita nas regiões de memória fornecida. Um criador de perfil pode usar a assinatura de metadados da função para interpretar sistema autônomo argumentos, sistema autônomo mostrado na tabela a seguir.

ELEMENT_TYPE	Representação
Primitivos (ELEMENT_TYPE<= R8, I, U)	Valores primitivos.
Tipos de valor (VALUETYPE)	Depende do tipo.
Tipos de referência (CLASS, STRING, OBJECT, ARRAY, GENERICINST, SZARRAY)	ObjectID (ponteiro em um lixo coleção heap).
BYREF	Ponteiro gerenciado (não um ObjectIDmas pode estar apontando para uma pilha de coleção de pilha ou lixo).
PTR	Ponteiro não gerenciado (não móveis pelo lixo coleção).
FNPTR	Tamanho de ponteiro valor opaco.
TYPEDBYREF	Gerenciado ponteiro, seguido de um valor opaco em tamanho de ponteiro.

sistema autônomo diferenças entre um ObjectID e um ponteiro gerenciado são da seguinte maneira:

ObjectIDponto de s somente no heap de coleta de lixo ou heap de objeto congelada. Ponteiros gerenciado também podem apontar para a pilha.
ObjectIDs sempre apontar para o início de um objeto. Ponteiros gerenciado podem apontar para um dos campos do objeto.
Ponteiros gerenciado não podem ser passados para funções que esperam um ObjectID.

Consulte o CorElementType enumeração para obter uma lista dos tipos CLR disponível.

Inspecionando tipos complexos

Inspecionar tipos de referência ou tipos de valor não primitivo envolve algumas técnicas avançadas.

Valor de referência e tipos de tipos diferentes de seqüências de caracteres ou matrizes, o ICorProfilerInfo2::GetClassLayout método fornece o deslocamento para cada campo. O criador de perfil pode usar os metadados para determinar o tipo do campo e recursivamente avaliá-lo.

Observação:
GetClassLayout Retorna somente os campos que são definidos pela própria classe; os campos definidos pela classe pai não são incluídos. Você pode usar o ICorProfilerInfo2::GetClassIDInfo2 método para localizar o ClassID da classe pai e, em seguida, uso GetClassLayout Para obter informações sobre os campos definidas pela classe pai.

Para tipos de valor convertidos, o ICorProfilerInfo2::GetBoxClassLayout método fornece o deslocamento do tipo de valor na caixa. Não altera o layout do tipo de valor. Portanto, assim que o criador de perfil encontrou o tipo de valor na caixa, ele pode usar GetClassLayout Para entender seu layout.

Para seqüências de caracteres, a ICorProfilerInfo2::GetStringLayout método fornece os deslocamentos da partes interessantes de dados no objeto de seqüência de caracteres.

Arrays são um pouco especiais que deve chamar um método para cada objeto de matriz em vez de cada tipo de matriz. (Isso ocorre porque há muitos formatos de matriz para descrever por meio de deslocamentos.) The ICorProfilerInfo2::GetArrayObjectInfo método é fornecido para fazer a interpretação.

Inspecionando campos estático

Há quatro tipos de campos estático. A tabela a seguir descreve o que são e como identificá-los.

Tipo estático	Definição	Como ela aparece em metadados
AppDomain	O campo estático básico. Ele tem um valor diferente em cada domínio do aplicativo.	Campo estático que tem não anexado atributos personalizados.
Thread	Gerenciar armazenamento thread local (TLS). Este é um campo estático com um valor exclusivo para cada segmento e cada domínio do aplicativo.	Campo estático marcado com ThreadStaticAttribute.
RVA	Escopo do processo de campo estático com uma residência na seção de dados do módulo.	Campo estático com hasRVA sinalizar.
Contexto	Campo estático com um valor diferente em cada contexto COM +.	Campo estático marcado com ContextStaticAttribute.