Inspección de objetos en la API de generación de perfiles

2011-08-10

En este tema se explica cómo usar métodos de generación de perfiles para inspeccionar objetos.

Devoluciones de llamada FunctionEnter2 y FunctionLeave2

Las devoluciones de llamada FunctionLeave2 y FunctionEnter2 proporcionan información sobre los argumentos y el valor devuelto por una función, en forma de regiones de memoria. Los argumentos se almacenan de izquierda a derecha en regiones de memoria determinadas. Un generador de perfiles puede utilizar la firma de metadatos de la función para interpretar los argumentos, como se muestra en la tabla siguiente.

ELEMENT_TYPE	Representación
Primitivas (ELEMENT_TYPE < = R8, I, U)	Valores primitivos.
Tipos de valor (VALUETYPE)	Depende del tipo.
Tipos de referencia (CLASS, STRING, OBJECT, ARRAY, GENERICINST, SZARRAY)	ObjectID (puntero a un montón de recolección de elementos no utilizados).
BYREF	Puntero administrado (no un ObjectID, pero puede estar señalando a una pila o montón de recolección de elementos no utilizados).
PTR	Puntero no administrado (no movible por recolección de elementos no utilizados).
FNPTR	Valor opaco dimensionado por puntero.
TYPEDBYREF	Puntero administrado, seguido por un valor opaco dimensionado por puntero.

Las diferencias entre un ObjectID y un puntero administrado son las siguientes:

Los ObjectID señalan solamente al montón de recolección de elementos no utilizados o al montón de objetos inmovilizados. Los punteros administrados también pueden señalar a la pila.
Los ObjectID siempre señalan al principio de un objeto. Los punteros administrados pueden señalar a uno de los campos del objeto.
Los punteros administrados no se pueden pasar a funciones que esperen un ObjectID.

Vea la enumeración CorElementType para obtener una lista de tipos de CLR disponibles.

Inspeccionar tipos complejos

Inspeccionar tipos de referencia o tipos de valor no primitivos implica algunas técnicas avanzadas.

Para los tipos de valor y de referencia distintos de cadenas o matrices, el método ICorProfilerInfo2::GetClassLayout proporciona el desplazamiento para cada campo. El generador de perfiles puede utilizar entonces los metadatos para determinar el tipo del campo y evaluarlo de forma recursiva.

Nota
GetClassLayout devuelve sólo los campos definidos por la propia clase; los campos definidos por la clase primaria no se incluyen.Puede utilizar el método ICorProfilerInfo2::GetClassIDInfo2 para buscar ClassID de la clase primaria y, a continuación, utilizar GetClassLayout para obtener información sobre los campos definidos por la clase primaria.

Para los tipos de valor de conversión boxing, el método ICorProfilerInfo2::GetBoxClassLayout proporciona el desplazamiento del tipo de valor dentro de la conversión boxing. El propio diseño del tipo de valor no cambia. Por consiguiente, tan pronto como el generador de perfiles encuentra el tipo de valor dentro de la conversión boxing, puede utilizar GetClassLayout para comprender su diseño.

Para las cadenas, el método ICorProfilerInfo2::GetStringLayout proporciona los desplazamientos de fragmentos interesantes de datos en el objeto de cadena.

Las matrices son especiales tanto que se debe llamar a un método para cada objeto de matriz, en lugar de cada tipo de matriz. (Esto se debe a que hay demasiados formatos de matriz para describirlos utilizando desplazamientos.) El método de ICorProfilerInfo2::GetArrayObjectInfo se proporciona para hacer la interpretación.

Inspeccionar campos estáticos

Hay cuatro tipos de campos estáticos. En la tabla siguiente se describe lo que son y cómo identificarlos.

Tipo estático	Definición	Cómo aparece en los metadatos
AppDomain	El campo estático básico. Tiene un valor diferente en cada dominio de aplicación.	Campo estático que no tiene ningún atributo personalizado asociado.
Subproceso	Almacenamiento local de subprocesos administrado (TLS). Éste es un campo estático con un valor único para cada subproceso y cada dominio de aplicación.	Campo estático marcado con ThreadStaticAttribute.
RVA	Campo estático de ámbito de proceso con sede en la sección de datos del módulo.	Campo estático con marcador hasRVA.
Contexto	Campo estático con un valor diferente en cada contexto COM+.	Campo estático marcado con ContextStaticAttribute.