6 messages in net.java.dev.jna.usersRe: [jna-users] Debugging memory leaks
FromSent OnAttachments
Stas OskinAug 5, 2008 6:02 am 
Michael Brewer-DavisAug 5, 2008 7:46 am 
Stas OskinAug 6, 2008 1:15 am 
Timothy WallAug 6, 2008 5:08 am 
Stas OskinAug 7, 2008 6:42 am 
Timothy WallAug 7, 2008 7:05 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [jna-users] Debugging memory leaksActions...
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++?