Базовая статистика использования кучи в GCC на 64-битной платформе
Мне нужно ответить на основной вопрос изнутри моей C-программы, скомпилированной GCC для Linux: сколько кучи процессов используется в настоящее время (выделено malloc) и сколько стоит, если свободные блоки кучи. GNU реализация стандартной библиотеки имеет mallinfo функция, которая сообщает именно то, что мне нужно, но ее можно использовать только с 32-битными конфигурациями, и, AFAIK, нет 64-битного эквивалента этой функциональности (кстати, кто-нибудь знает почему?).
Я использую GCC в Linux, поэтому мне нужно это для Linux. Но я предполагаю, что куча непрозрачна для системы, поэтому единственный способ ответить на этот вопрос - использовать средства, предоставляемые реализацией стандартной библиотеки.
В реализации MSVC на платформе Windows нет эквивалента mallinfo функция, но есть так называемая функциональность обхода кучи, которая позволяет вычислять необходимую информацию путем перебора всех блоков в куче. AFAIK, в библиотеке GNU C нет интерфейса кучи. (Есть?).
Итак, опять же, что мне делать в GCC? Это не обязательно должно быть эффективно, а это означает, что вышеупомянутый подход, основанный на кучи, будет работать для меня совершенно нормально. Как узнать, сколько кучи используется и сколько свободно в GCC? Я, вероятно, могу попробовать установить malloc-hooks и "вручную" отслеживать размеры, хотя я не уверен, как определить текущий размер арены кучи (см. mallinfo.arena) без использования mallinfo,
1 ответ
Этот поток 2004 года, в котором участвуют ключевые разработчики glibc, указывает, что, поскольку интерфейс уже "... не соответствует реализации". было мало смысла в создании 64-битной чистой версии. (The mallinfo() интерфейс не был разработан для glibc - он рассматривался для включения в SUS).
В зависимости от того, что вы пытаетесь сделать с информацией, вы можете использовать malloc_stats(), который просто производит вывод при стандартной ошибке - так как это просто текстовый вывод, он может измениться, чтобы соответствовать внутренней реализации malloc()и, следовательно, по крайней мере, будет иметь преимущество в получении ощутимых результатов.