Comments
6 comments
-
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?
-
Hi Jessica,
Thanks for responding. The C++ component is unmanaged and accessed from the .NET layer through interop. -
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?
-
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!
-
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
-
Sounds good, Jessica. Thank you for responding and for the web links. I'll check them out
Add comment
Please sign in to leave a comment.
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?