2

My java jar is just one of many that a larger program uses. I am trying to determine if my code is the cause of a memory leak, or if there are other problems outside of my code. I am using jvisualvm, and have identified all of my classes, and none of them seem suspect. Looking at the sampler, i can see that byte[], char[], and int[] appear to be biggest users in terms of size and instances created. the problem is, that i can't determine who they belong to. I know that i have various byte[] in my program, but since there are some 32,000 instances, it is hard to determine the source looking at them one by one. Is there a way to filter the data so that only items originating from a certain jar or area can be viewed? Thanks.

Jason
  • 2,147
  • 6
  • 32
  • 40
  • 3
    I personally found MAT better for analysis work and easier to see incoming/outgoing references. Have you tried it? http://www.eclipse.org/mat/ – BunjiquoBianco Dec 12 '12 at 15:32
  • Can it link to externally running JVMs? – Jason Dec 12 '12 at 15:35
  • 1
    MAT works on heap dumps. Do you think you could get hold of one? – K Erlandsson Dec 12 '12 at 15:37
  • If you take a heap dump you should be able to see where objects are retained. VisualVM allows you to take a heap dump and load it for analysis. – Peter Lawrey Dec 12 '12 at 15:38
  • A heap dump? I'm sure JVisualVm allows me to save heap dumps. would that work? – Jason Dec 12 '12 at 15:38
  • @PeterLawrey - I believe the analysis part is where i'm having the trouble. I have created the heap dump in visualvm, and looked at the summary. I found the 40 biggest objects by retained size. There are a couple byte[] listed, but i still can't trace back and identify the class that created it. – Jason Dec 12 '12 at 15:49
  • You can only see why they are being retained, which is what you need to fix to prevent the memory leak. I suspect VisualVM can't tell you where they were allocated as well. – Peter Lawrey Dec 12 '12 at 15:53
  • Unless you know you are creating a lot of byte[] or String instances, I wouldn't put money on byte[] or char[] being the source of the issue. Concentrate on unusual amounts of objects you know *you* are creating, even if they aren't the biggest things in the heap. MAT will be able to open heap dumps from VisualVM I think - pretty sure VVM uses hprof format. – BunjiquoBianco Dec 12 '12 at 15:56
  • I installed MAT in eclipse, but there is no option for me open the heap dump. I'm going to have to spend some time to sort that out. – Jason Dec 12 '12 at 16:16
  • @BunjiquoBianco - i have installed and analyzed the heap dumps as best i can. MAT definitely provided more insight into the potential of memory leaks. thanks. – Jason Dec 12 '12 at 19:27
  • @BunjiquoBianco - can you put your comments into a proposed answer so i can mark it? – Jason Dec 12 '12 at 19:28

1 Answers1

2

Unless you know you are creating a lot of byte[] or String instances, I wouldn't put money on byte[] or char[] being the source of the issue. Pretty much every heap I've dug through has loads of these as they're used in many bits of java's internals. I'm not saying that they can't be the issue, but it's more fruitful to first concentrate on unusual amounts of objects you know you are creating, even if they aren't the biggest things in the heap.

I personally found MAT better for analysis work than VisualVM, although VisualVM is great for monitoring memory usage on the fly and watching GC cycles.

MAT also allows you to drill down to see incoming and outgoing reference to the retained objects. This will give you a better picture of which objects are holding onto more memory than you expect and should help you to find out whether one of the objects from your JAR is the culprit.

The help documentation included with MAT is pretty good and definitely worth a read to help get you started.

If you want to get even further into the rabbit hole read up on OQL which you can use to query the heap in both MAT and VisualVM.

MAT can be found here: http://www.eclipse.org/mat/

I dug out some background reading (some of which is a bit dated, but still relevant to paint a better picture of how to approach the problem)

Leaks are easy to find, but memory usage analysis is bit more difficult
Memory leaks are easy to find
Finding memory leaks with SAP memory analyser

It's also worth understanding a bit about GC when looking at the heap so worth a flick through these:
GC Tuning
Diagnosing a Garbage Collection problem

BunjiquoBianco
  • 1,994
  • 2
  • 21
  • 24
  • Thanks for the info. I will read up today. Some testing that i have been doing with my code not running at all has also pointed to other sources as the memory leaks. It's nice to see that MAT has shown that and testing has backed it up. – Jason Dec 13 '12 at 13:45