通过JNI监视使用Java调用的C DLL的内存使用情况？

Question

How can I monitor the memory being used by a native C DLL that is being called from Java via JNI? Using standard Java monitoring tools and options I can see the Java memory space, but I cannot view any memory used by the C DLL. Java is using ~70MB, but the task in the Task Manager shows 200Mb+, and I'd like to see what's in that 130MB extra if possible.

Answer 1

You can monitor the native heap with counters in the performance montitor. (perfmon32) however it wont break it down for you on a per DLL basis, even jvm.dll will be included here.

Most profiling tools out there can attach to a process and capture and track memory allocations and deallocations. This allows them to speculate where leaks are. One pretty good one i found when recently trying to track down memory leaks in native code which was called from Java is Memory Validator

Answer 2

Have you tried using Process Viewer to dig deeper.

If you have the source to the DLL you could rebuild with debug libraries and possibly a mem allocation tracker - and debug using visual C++ debugger (you'll need to tell it to use the java application).

If you haven't got the source - then the options are limited.

Answer 3

I believe even doing this inside the C DLL would not be very easy.

As far as I understand the Standard Java Monitoring tools gather information by querying the Virtual Machine, thus even though that memory is in the same process unless the virtual machine knows how to inspect your dynamically linked library, it won't be able to see anything. I believe you would need to use an external tool or make somewhat massive modifications to the DLL in order to track its memory usage.

Answer 4

Well, since the DLL isn't really part of the Java heap, I think the most accurate reading would be to write a small profiling program (either a small a Java/JNI program or C++/C#, etc) to import and use the DLL in a similar way to your application and do NOTHING ELSE - just use the DLL as you do - the resulting memory profile of this profiling app should be a good approximation to the memory profile of the DLL.

You should also test to see if there's a static or dynamic memory shape of the DLL - take memory measurments directly before and after the DLL is loaded to see if there's a one-time hit of ~130MB, or if the memory slowly goes up over time.

On Solaris / Linux, I've heard that the Sun Studio Collector / Analyzer is a good tool for this, but you're stuck in DLL-land (or DLL hell, as it were)