Estoy usando VMMap para analizar la utilización del espacio de direcciones virtual / de proceso en mi aplicación de modo mixto (administrada y no administrada). Entiendo cómo funciona Windows VMM y la API de memoria virtual, también entiendo cómo funciona la API de memoria de almacenamiento dinámico. He analizado la implementación de CRT que estoy usando (no en gran detalle) y (creo que esto podría ser mi ruina) entiendo cómo esto usa las API de Win32 antes mencionadas.

Estoy buscando entender qué me muestra esta estadística de "Datos privados". Mi aplicación no realiza llamadas directas a ninguna de las funciones de la API de memoria Win32, solo usa "malloc / new" en C ++ nativo y "new" en C # (que en el fondo utilizará la API de administración de memoria Win32).

La definición de "Datos privados" dada por VMMap es:

La memoria privada es memoria asignada por VirtualAlloc y no subasignada ni por el Administrador de almacenamiento dinámico ni por el tiempo de ejecución de .NET. No se puede compartir con otros procesos, se carga contra el límite de confirmación del sistema y generalmente contiene datos de la aplicación.

Entonces, supongo que esta definición me hace preguntar, ok, ¿quién está haciendo las llamadas a VirtualAlloc? ¿Es el Heap Manager o el tiempo de ejecución de .Net?

Podría obtener una dirección de algunos de los datos privados comprometidos y usar WinDbg para averiguarlo ... Bueno ... resulta que Microsoft, en su sabiduría, ha ocultado los símbolos públicos ntdll, por lo que WinDbg no funciona tan bien. puede proporcionar más detalles sobre esto si se solicita, pero básicamente comandos como! address -summary ya no funcionan debido a la falta de símbolos.

Otra forma de formular esta pregunta podría ser: ¿Qué código C ++ o C # puedo escribir que haga que esta estadística de datos privados aumente o disminuya? ¿O todo esto es administrado por el sistema operativo, el tiempo de ejecución de C ++ o el tiempo de ejecución de .Net y, por lo tanto, a merced de sus caprichos?

Puedo deducir de la naturaleza de VMMap (otros tipos de memoria son EXCLUSIVOS DE CUALQUIER OTRO) que estos "datos privados", por lo tanto, no pueden ser ninguno de los siguientes tipos de espacio de direcciones:

Heap (tenga en cuenta que esto incluye el espacio de heap reservado Y reservado: reservado mediante una llamada a VirtualAlloc, como se describe en la descripción de los datos privados más arriba).Montón administradoApilarCompartibleArchivo mapeadoImagenTabla de la páginaInutilizableGratis

(No pude encontrar un archivo de ayuda en línea que defina qué VMMap cree que son todos los tipos anteriores, pero aquí hay un enlace para descargar el archivo de ayuda:https://technet.microsoft.com/en-us/library/dd535533.aspx)

Me di cuenta de que en mi aplicación, el tamaño TOTAL (reservado y comprometido) de los datos privados permanece bastante constante a lo largo de la vida útil de mis aplicaciones, a pesar de que los tamaños de Montón / Montón administrado / Pila cambian como se esperaba. También he notado que del ~ 250Mb total utilizado por datos privados, solo ~ 33Mb están realmente comprometidos. Tenga en cuenta que mi método para medir esto es bastante rudimentario, por lo que el valor puede estar cambiando entre cada una de mis mediciones y simplemente no lo veo (si supiera lo que esto estaba midiendo, podría usar DebugDiag para obtener un volcado del proceso cuando el contador relacionado alcanzó cierto umbral, pollo y huevo).

Mi teoría especulativa actual es que este es el espacio que se reserva para cultivar los montones nativos (¿o supongo que manejados?) A medida que alcanzan su capacidad, pero no tengo nada que lo demuestre. Por lo tanto, permanece firmemente en la pila especulativa.

Buscar detalles en Internet sobre esto puede ser doloroso, hay muchas publicaciones / artículos / blogs que confunden las cosas, usan definiciones autorreferenciales (la primera oración de la definición de Performance Monitor para Working Set es un gran ejemplo de esto). incompletos o simplemente están equivocados. Muchos lugares difuminan las definiciones o usan una terminología inconsistente (tenga en cuenta que la definición de VMMaps de los datos privados del campo, se refiere a ella como memoria privada, quizás una queja anal, pero ambigüedad).

Ahora que he criticado al resto de Internet por confundir las cosas e incorrectamente ... si hay algo en lo anterior que no tiene sentido o puede mostrarme documentación en contrario o necesita una definición más explícita de , avísame y también me pondré en la lista de delincuentes. Creo que la primera mitad de tratar de explicar un problema de memoria a alguien, en línea, es asegurarnos de que todos estamos hablando de lo mismo.

Finalmente esta pregunta:¿Cómo sabe VMMap que una región de memoria dada es Thread Stack, específicamente? sugiere que tal vez nunca encuentre una respuesta: /

ACTUALIZACIÓN / EDICIÓN: descubrí que al activar el seguimiento de pila de usuarios de gflags (gflags -i myapp.exe + ust), puede aumentar el tamaño de los datos privados, supongo que esta es la base de datos de seguimiento, pero incluso sin gflags , todavía hay datos privados que estoy luchando por tener en cuenta.