Как я могу контролировать память, используемую собственной DLL C, которая вызывается из Java через JNI? Используя стандартные инструменты и параметры мониторинга Java, я могу видеть пространство памяти Java, но не могу просматривать память, используемую C DLL. Java использует ~ 70 МБ, но задача в диспетчере задач показывает 200 МБ +, и я хотел бы посмотреть, что в этих 130 МБ дополнительных, если возможно.




Вы пробовали использовать Наблюдатель процессов, чтобы копнуть глубже.
Если у вас есть источник DLL, вы можете перестроить его с помощью библиотек отладки и, возможно, трекера распределения памяти - и отладить с помощью визуального отладчика C++ (вам нужно будет указать ему использовать приложение java).
Если у вас нет исходников - тогда возможности ограничены.
если у вас есть источник, вы можете перестроить и отладить из VS ... (см. расширение для ответа)
Я считаю, что даже сделать это внутри C DLL будет непросто.
Насколько я понимаю, стандартные инструменты мониторинга Java собирают информацию, запрашивая виртуальную машину, поэтому, даже если эта память находится в том же процессе, если виртуальная машина не знает, как проверять вашу динамически подключаемую библиотеку, она не сможет ничего увидеть. . Я считаю, что вам нужно будет использовать внешний инструмент или внести несколько значительных изменений в DLL, чтобы отслеживать использование памяти.
Инструменты мониторинга Java предоставляют информацию только о куче Java и не сообщают о какой-либо памяти, прикрепленной к процессу Windows для собственных вызовов.
Что ж, поскольку DLL на самом деле не является частью кучи Java, я думаю, что наиболее точным чтением было бы написать небольшую программу профилирования (либо небольшую программу Java / JNI, либо C++ / C# и т. д.), Чтобы импортировать и использовать DLL аналогично вашему приложению и НИЧЕГО НЕ ДЕЛАЙТЕ - просто используйте DLL, как вы делаете - результирующий профиль памяти этого приложения для профилирования должен быть хорошим приближением к профилю памяти DLL.
Вы также должны проверить, есть ли у DLL форма памяти статический или динамичный - измерьте память непосредственно до и после загрузки DLL, чтобы увидеть, есть ли одноразовое попадание в ~ 130 МБ или медленно ли увеличивается память время.
В Solaris / Linux я слышал, что сборщик / анализатор Sun Studio - хороший инструмент для этого, но вы застряли в DLL-пространстве (или, как это было, в аду DLL)
Вы можете контролировать собственную кучу с помощью счетчиков в мониторе производительности. (perfmon32), однако он не разбивает его для каждой библиотеки DLL, даже jvm.dll будет включен здесь.
Большинство инструментов профилирования могут подключаться к процессу и фиксировать и отслеживать выделение и освобождение памяти. Это позволяет им догадываться, где утечки. Один довольно хороший, который я обнаружил, когда недавно пытался отследить утечки памяти в собственном коде, который был вызван из Java, - это Валидатор памяти.
Спасибо за подсказку, Деклан, попробую в понедельник.
Мониторинг использования памяти в JNI DLL, вызываемой из Java softwareverify.com/software-verify-blog/?p=221
Это дает мне дополнительную информацию, Ричард, но ее недостаточно, чтобы определить место утечки. Тем не менее, Process Viewer - отличный инструмент в наборе инструментов для любого Windows-разработчика!