

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
6 messages in net.java.dev.jna.usersRe: [jna-users] Debugging memory leaks| From | Sent On | Attachments |
|---|---|---|
| Stas Oskin | Aug 5, 2008 6:02 am | |
| Michael Brewer-Davis | Aug 5, 2008 7:46 am | |
| Stas Oskin | Aug 6, 2008 1:15 am | |
| Timothy Wall | Aug 6, 2008 5:08 am | |
| Stas Oskin | Aug 7, 2008 6:42 am | |
| Timothy Wall | Aug 7, 2008 7:05 am |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [jna-users] Debugging memory leaks | Actions... |
|---|---|---|
| From: | Stas Oskin (stas...@gmail.com) | |
| Date: | Aug 7, 2008 6:42:59 am | |
| List: | net.java.dev.jna.users | |
Hi.
Thanks for the tip, I've found the spot.
Problem is, it looks perfectly good, there is de-allocation functions, several lines before the allocation one.
As profiling displayed to me that the number of active objects is constantly rising, I placed a call to GC directly beneath the de-allocator. This seemed to help, and dropped the number of active objects, and their used memory, to about same level.
Problem now, is that I have heavy performance penalty because of GC calls.
So my question is: 1) Why the memory keeps leaking without explicit calls to GC? 2) What's the best way to solve it without getting heavy performance hit?
Thanks again.
2008/8/6, Timothy Wall <twal...@dev.java.net>:
You can use the NetBeans profiler to track the allocation locations of the offending allocation types.
On Aug 6, 2008, at 4:16 AM, Stas Oskin wrote:
Hi.
Thanks for your reply.
To isolate whether the memory being leaked is C memory or Java memory, I'd start by asking the Java runtime how much memory it's managing. See java.lang.Runtime.totalMemory(), or some of the debug options for garbage collection at
http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/gdaog.html
If it's Java memory being leaked, I use Netbeans or its little cousin visualvm to walk the heap, but there are other tools out there.
I tested with VisualVM, and found out that "java.lang.reflect.Field" object is probably the source of the leak. It size rises about 40MB per second.
"byte[]" object raises as well, but much more steadily (about several bytes), and I think it's related to the above.
Any idea how can I continue from here? Especially, is there any way to find the location of the leak, like with Valgrind for C++?







