Would Java Native Interface objects instantiated in C++ appear in the ANTS Profiler as C++ leaks

concordia_1580

We have a web application that calls into a C++ component.  The C++ component uses a JNIEnv_ pointer to make calls to CallObjectMethod in the Java Virtual Machine.  In each case the pointers returned get assigned to local objects of types such as jobject and jstring.  Also, in each case, DeleteLocalRef is called on the JNIEnv_ pointer so the Java garbage collector knows it is free to deallocate the memory.

Additionally, we've verified the C++ code itself has no leaks by using the C language runtime function _CrtDumpMemoryLeaks().

In spite of all this we know from the ANTS Profiler that the C++ component is responsible for the vast majority of the memory leaks.

Consider the local objects in C++ code such as the jobjects and jstrings mentioned above.  If, for whatever reason, the Java garbage collector doesn't have time to dispose of these after the call to DeleteLocalRef and before control leaves the C++ function, could these objects masquerade as leaking C++ objects and therefore be reported by ANTS as part of the C++ component rather than part of the JVM?

Jessica R

Thank you!

The unmanaged memory breakdown should be accurate, so going back to the original question:"could these objects masquerade as leaking C++ objects and therefore be reported by ANTS as part of the C++ component rather than part of the JVM?" - It depends on how the memory is allocated by either jvm or EZGeoInt as that could indeed cause the reported memory to be a part of one or the other module but we unfortunately don't know enough to say for sure .

AMP has limited capabilities of finding memory leaks in unmanaged modules so tracking down such leaks may be significantly harder than for regular managed objects.  If it's any help though, we advise following the documentation for analyzing unmanaged memory problems, keeping in mind that AMP is only able to point in the general direction of where the unmanaged memory may be leaking:

https://documentation.red-gate.com/amp10/strategies-for-memory-profiling/checking-unmanaged-memory-usage
https://documentation.red-gate.com/amp10/working-with-profiling-results/the-summary-page#Thesummarypage-Unmanagedmemorybreakdownbymodule
https://documentation.red-gate.com/amp10/understanding-memory-problems/memory-management-primer#Memorymanagementprimer-Unmanagedmemoryleaks

concordia_1580

Sounds good, Jessica.  Thank you for responding and for the web links.  I'll check them out

Jessica R

Hi @concordia_1580,

Thanks for your post!

I unfortunately don't know much about how memory for Java is handled, but just to confirm, is the C++ component you mentioned a managed C++ component?

concordia_1580

Hi Jessica,
Thanks for responding.  The C++ component is unmanaged and accessed from the .NET layer through interop.

Jessica R

Thanks @concordia_1580!

You mentioned "In spite of all this we know from the ANTS Profiler that the C++ component is responsible for the vast majority of the memory leaks."

Could you provide more detail on how ANTS confirmed this for you?

concordia_1580

Sure.  Attached is a screen shot of the unmanaged memory breakdown by module.  Our C++ component is named EZGeoInt.  Notice the JVM is only 5 MB but EZGeoInt is 522 MB.  So considering the information I provided in my original post, this result made me wonder if leaks associated with the Java native interface objects declared in EZGeoInt are being reported by ANTS as C++ leaks rather than JVM leaks. Thank you!