How do I record and graph the object lifetime for Java applications?

We want to tune the memory generation pool sizes for our Java application. In order to this we need to first understand how the heap is used. In essence we need to know number, size and lifetime for every object in the JVM heap. After we have collected this data we should be able to find better suited sizes for our young and tenured generation pools.

We base our tuning efforts on information found in the "Tuning Garbage Collection with the 5.0 JVM" whitepaper from Sun/Oracle. In section 3 (http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#1.1.%20Generations%7Coutline) they discuss generation sizing and show an example on an object lifetime graph. Pretty much what we are trying to achieve for our application.

So far we have been 开发者_如何学运维able to record the number of instances for a given class and their respective sizes in memory. However I am unable to find a way to extract an average instance life length. Right now we are looking into jProfiler but so far without success.

Has anybody been successful in graphing the average object lifetime for Java applications?

To tune the GC you typically don't need the lifetime of every object, but a good realtime overview of the pools. The first thing I usually do is to look at the various pools using visualgc which is part of jvmstat (http://java.sun.com/performance/jvmstat/). Then I move on to check for potential memory leaks. This is by far the best way I've come across.

A. In jconsole you can see if you are constantly overflowing into the old gen prematurely (meaning that the eden was too big to fit in the survivor even after it's gc). Should this be the case, check your young size and survivor ratio and try to adjust them so that it doesn't overflow.

B. Also, during "normal" operation it's a good idea to look at the histogram of survivor generations in visualgc and make sure the generations are empty well ahead of becoming too old.

If they do spill over this way, you could potentially have a memory leak. I would then dump the memory with jconsole and have a look at it with MAT (http://www.eclipse.org/mat/):

1. Launch jconsole.exe and invoke operation dumpHeap() on HotSpotDiagnostic MBean (make sure the filename ends with .hprof)
2. Open the dump in MAP and see if you recognize any type of object occupying more space than you would expect.

Good luck.