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.
+1
A:
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.
Richard Harrison
2008-10-08 20:56:25
This gives me some more information, Richard, but not quite enough to determine where the leak is. The Process Viewer is an excellent tool to have in the toolkit for any Windows-based developer, though!
lawsonj2019
2008-10-10 19:06:20
if you've got the source then you could rebuild and debug from VS... (see expansion to answer)
Richard Harrison
2008-10-16 20:34:10
A:
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.
luke
2008-10-08 21:04:31
The Java monitoring tools only give information on the Java heap, and don't report any of the memory attached in the process by Windows for the native calls.
lawsonj2019
2008-10-10 19:07:18
A:
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)
scotta
2008-10-08 21:08:45
+3
A:
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
Declan Shanaghy
2008-10-09 00:13:45
Monitoring memory use in a JNI DLL called from Javahttp://www.softwareverify.com/software-verify-blog/?p=221
Stephen Kellett
2010-05-08 13:42:23