Estadísticas básicas de uso del montón en GCC en plataforma de 64 bits

Question

Necesito responder una pregunta básica desde dentro de mi programa C compilada por GCC para Linux: cuánto del proceso está en uso actualmente (asignado por malloc) y cuánto reside si bloques de montón libres. La implementación GNU de la biblioteca estándar tiene la función mallinfo que informa exactamente lo que necesito, pero solo se puede usar con configuraciones de 32 bits y, AFAIK, no hay un equivalente de 64 bits de esa funcionalidad (por cierto, ¿alguien sabe por qué?).

Uso GCC en Linux, entonces lo necesito para Linux. Pero supongo que el montón es opaco para el sistema, por lo que la única manera de responder a esta pregunta es usar los medios proporcionados por la implementación de la biblioteca estándar.

En la ejecución MSVC en la plataforma Windows que no hay equivalente de mallinfo función, pero no es tan llamado funcionalidad de lixiviación en pie, lo que permite calcular la información necesaria por iteración a través de todos los bloques del montón. AFAIK, no hay una interfaz Heap-walk en la biblioteca C de GNU. (¿Esta ahí?).

Entonces, de nuevo, ¿qué hago en GCC? No tiene por qué ser eficiente, lo que significa que el enfoque basado en caminar montones antes mencionado funcionaría perfectamente bien para mí. ¿Cómo averiguo cuánto montón está en uso y cuánto es gratis en GCC? Probablemente pueda intentar instalar Malloc-hooks y rastrear "manualmente" los tamaños, aunque no estoy seguro de cómo determinar el tamaño actual de la arena del montón (ver mallinfo.arena) sin usar mallinfo.

Answer 1

This thread from 2004 que implica desarrolladores clave glibc indica que ya que la interfaz ya "... no se ajusta a la implementación en absoluto.", se consideró que tenía poco sentido hacer una versión limpia de 64 bits. (La interfaz mallinfo() no se diseñó para glibc; se estaba considerando su inclusión en el SUS).

Dependiendo de lo que intente hacer con la información, es posible que pueda usar malloc_stats(), que solo produce salida en error estándar, ya que es solo un resultado textual que puede cambiar para coincidir con la implementación interna de malloc(), y, por lo tanto, al menos tendrá la ventaja de producir resultados razonables.