Monitoring memory usage for a C DLL called using Java via JNI?

Question

How can I control the memory used by the embedded C DLL, which is called from Java via JNI? Using standard Java monitoring tools and options, I can see the Java memory space, but I can’t see the memory used by the C DLL. Java uses ~ 70 MB, but the task in the task manager shows 200 MB +, and I would like to see that there is 130 MB in addition, if possible.

Answer 1

You can control your own heap using counters in the performance monitor. (perfmon32), however it will not break it for you based on DLL, even here jvm.dll will be included.

Most of the profiling tools there can join the process, capture and track memory allocations and deallocations. This allows them to reflect on where the leaks are. One pretty good one I found when I recently tried to track memory leaks in native code that was called from Java, the "Memory Validator"

Answer 2

You tried to use the Process Viewer to dig deeper.

If you have a source for the DLL, you can rebuild it using the debug libraries and possibly track the placement of mem, and debug using the C ++ visual debugger (you will need to tell it to use the java application).

If you do not have a source, the parameters are limited.

Answer 3

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

As far as I understand, standard Java monitoring tools collect information by querying the virtual machine, however, although this memory is in the same process, unless the virtual machine knows how to check your dynamically linked library, it will not be able to see anything. I believe that you will need to use an external tool or make some significant changes to the DLL to track its memory usage.

Answer 4

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

You should also check if there is a static or dynamic form of memory in the DLL - take memory measurements immediately before and after loading the DLL to see if there is a single click of ~ 130 MB, or if the memory grows slowly over time.

On Solaris / Linux, I heard that the Sun Studio Collector / Analyzer is a good tool for this, but you are stuck in a DLL-land (or some kind of DLL-hell, sort of)