memory leaks

[Brandon McCombs]

hello,

My java application seems to use more memory than another application
that does something very similar and I'm trying to figure out if the
differences between the apps are causing the different in memory usage
or if it's really something like a memory leak in my app that I need to
fix. The memory difference is about 50 megs and it causes my app to hit
the java heap space limit very easily when running it in Eclipse. My app
dramatically increases in size as I fill in more information in a JTree
however the other app stays at about the same usage.

The question I have is what can I use (profiler, debugger, etc.) to tell
me what variable(s) are the ones that are taking up enormous amounts of
memory? I've tried the Eclipse debugger and I notice that a list model
that I use gets bigger however the actual data stored in it is the right
amount with the remaining elements actually being set to null. I assume
that means that it isn't taking up more memory than it is supposed to so
I think I should look elsewhere but I don't know where and maneuvering
through the eclipse debugger is tedious. It would be nice to find
something that can easily show me all my variables and list their sizes
as my program runs. I know a profiler will show me the memory usage is
increasing but will it easily help me find a memory leak if there is one?

Any suggestions?

thanks
Brandon

 

[Jeff]

hello,

My java application seems to use more memory than another application
that does something very similar and I'm trying to figure out if the
differences between the apps are causing the different in memory usage
or if it's really something like a memory leak in my app that I need to
fix. The memory difference is about 50 megs and it causes my app to hit
the java heap space limit very easily when running it in Eclipse. My app
dramatically increases in size as I fill in more information in a JTree
however the other app stays at about the same usage.

The question I have is what can I use (profiler, debugger, etc.) to tell
me what variable(s) are the ones that are taking up enormous amounts of
memory? I've tried the Eclipse debugger and I notice that a list model
that I use gets bigger however the actual data stored in it is the right
amount with the remaining elements actually being set to null. I assume
that means that it isn't taking up more memory than it is supposed to so
I think I should look elsewhere but I don't know where and maneuvering
through the eclipse debugger is tedious. It would be nice to find
something that can easily show me all my variables and list their sizes
as my program runs. I know a profiler will show me the memory usage is
increasing but will it easily help me find a memory leak if there is one?

Any suggestions?

thanks
Brandon

Might try forcing a garbage collection. Actually, it just suggests to
the JVM that it might be a good time to take out the garbage.

System.gc();

/js

 

[John Ersatznom]

Might try forcing a garbage collection. Actually, it just suggests to
the JVM that it might be a good time to take out the garbage.

System.gc();

I'm not sure that's the problem here. The list model that's getting
bigger and clogging up with unused nodes is the problem, given that
apparently they aren't held with weak references of any kind. Either the
list is leaking in some screwy way, or it recycles a pool of nodes
internally but doesn't use SoftReference or similar to allow the gc to
get rid of these when space is getting tight.

This could be a JTree implementation issue.

Does the other application use JTree (or even Java at all)? If so, do
you have access to the source? See if they are doing anything different
with their JTree.

And by all means, give System.gc() a try; just don't expect much from it
but a lengthy pause in your GUI's response.

 

[Brandon McCombs]

I'm not sure that's the problem here. The list model that's getting
bigger and clogging up with unused nodes is the problem, given that
apparently they aren't held with weak references of any kind. Either the
list is leaking in some screwy way, or it recycles a pool of nodes
internally but doesn't use SoftReference or similar to allow the gc to
get rid of these when space is getting tight.

I fixed the list problem by just creating a new listmodel everytime I
needed to populate it with another tree node's children and made sure to
set the JList's model to the new listmodel everytime. It seems to allow
me to put the entire jtree in memory now although I still have memory
issues I believe. I posted something in the c.l.j.gui group titled
'memory allocation for a method' that talks about it. It should have
been in this group but I wasn't paying attention and posted it to the
gui group.

This could be a JTree implementation issue.

possibly but if you don't mind take a look at my other post that I
mention and see what you think.

Does the other application use JTree (or even Java at all)? If so, do
you have access to the source? See if they are doing anything different
with their JTree.

its another application that uses java and a jtree to implement an LDAP
client like my program. He does one thing fundamentally different which
is to not show a listmodel on the right side of the window but instead
shows the attributes of the selected node.

I show the children in the tree as well as in the listmodel for a
particular node. The children of a node stay in the tree as you go from
one node to another however the listmodel changes as you change nodes.
To view the attributes of an object you have to double click (or use a
pop up menu) on an entry in the listmodel so the jtree is more for
navigation although it can be used for add/deleting LDAP objects (just
not modifying them). The reason for this is that the nodes in the jtree
don't include any of the LDAP attributes; that's why I have the JList on
the right side of the window.

The other guy's app only uses a thread when he wants to read the
attributes of a single object. Currently I only use a thread to grab all
the children of a particular object but I just started to implement
threads so that may change.

It's possible to see all the children of a node in my app by just
selecting a node (and the children show up in the list) but in the other
app you have to expand the node to see the children since highlighting
the node shows the details of the node in the right pane.

The items in the listmodel already have all their attributes so a last
second thread to grab a clicked object's attribute isn't needed. This of
course requires more memory than the other app which grabs an object's
attributes when you want to view them after clicking on one in the jtree.

My other post describes another thing that seems to take up memory in my
app, at least based on JProfiler information.

And by all means, give System.gc() a try; just don't expect much from it
but a lengthy pause in your GUI's response.

Tried it; didn't see much difference as far as memory is concerned but I
expected that since the profiler shows that GC is already occurring
regularly.

 

[Lew]

Tried it; didn't see much difference as far as memory is concerned but I
expected that since the profiler shows that GC is already occurring
regularly.

It's pretty much never a good idea to call System.gc().

There are times, sure, but very specialized and not as a "throw it at the wall
to see if it sticks" response.

Assuming the JVM honors the request, it will do it with a major collection,
not just a young generation cleanup. This might be what you want, or not.

A more productive approach, if you understand the memory demands of your
application, might be to play with the "-XX" options that control the gc
parameters.

Personally that level of tuning seems like a dark art to me.

- Lew