Object Life Time Monitoring

Two years ago, in the dark ages before Java 5 (2004) I needed to do some Java profiling of the Herold website. Recent investigations using commercial profilers like JProbe had failed because their memory and CPU needs made the application virtually unresponsive. So I had to come up with some lightweight profiling solution of my own.

I was only concerned with memory consumption, as performance seemed to be bottle-necked by garbage collection. Based on a method described by Jack Shirazi in his book, I used PhantomReferences and a modified java.lang.Object to track object creation and garbage collection. That's all, very lightweight. Using this (Object) Life Time Monitor (LTM) I got an idea of the number of certain class instances created and active over time. A simple graphical viewer gave an overview of the collected data, the instances' life times, something like that:

Installation
Download LTM 1.01 (49 KB), together with source. It's JDK 1.3 compliant and does not depend on any other libraries. To use it with Java 1.4 extract the ltm-*.zip and put the LTM.jar into your bootclasspath. When using other JREs than 1.4, you have to modify your java.lang.Object as shown below and put it before LTM.jar into your bootclasspath.

// --- code added to object ---
public Object() {
   if (at.herold.test.objlifetime.MonitoringFlag.monitoring) {
     at.herold.test.objlifetime.ObjectLifetimeMonitoring.monitor(this);
   }
}
// --- code added to object ---

Usage
Start your application with LTM enabled by

java -Xbootclasspath/p:LTM.jar
     -cp <your application's classpath>
     at.herold.test.objlifetime.ObjectLifetimeMonitoring
     s
     <your application's main class>
     <your application's parameters if any>

Tell LTM to start collecting data with java -jar LTM.jar start on the same machine running the application. This enables the counting of objects. To stop collecting data run java -jar LTM.jar stop. The application will continue to run normally.

To save the recently collected raw data use java -jar LTM.jar save. This saves the raw data using a constant file name. The file is created in the current folder, depending on your start routines this might be windows/system32 or somewhere else. Now you may stop the application. You can view the saved data with java -jar LTMViewer.jar <raw file>. This loads, analyses and displays the object lifetime statistics. <raw file> is the file saved by LTM earlier. An JPG image is saved as well.

Source
In case you want to add or change something, there are the following Java packages: objlifetime contains the LTM core classes. Monitoring is managed by the AdminThread, which listens to a socket for commands. objlifetime.viewer contains the viewer to analyse the saved data from the LTM. Analysing classes are subclasses of LifeTimeAnalyser. The source is described in detail in the article Überwachung der Anzahl aktiver Objekte in JavaSPEKTRUM, 1/2006. LTM is Open Source under the GPL license.

FAQ
Q: When defining my own java.lang.Object where do I take it's implementation from? A: The original Object shipped with JDK is used. It's source can be found in the src.zip of the JDK. You just have to compile the new Object.java and put in in the bootclasspath before the LTM.jar (because it contains 1.4 Object.class already).

Q: What is all this 'bootclasspath' about? A: See Using the BootClasspath.

Q: Which type of file has to be passed as an argument to LTM? I am running this application by calling the Main.main() method and it's expecting a file name. A: The application is started as usual, LTM just has to sit in its bootclasspath. So <your application> is the qualified class name of the application you want to start for monitoring, e.g. com.company.app.Main. If you want to test a Tomcat web application you need to use the Catalina Bootstrap class here, as found in startup.sh/bat.

Words of Warning
LTM is a simplistic, very specialised kind of profiler. It was written in 2004 targeting J2SE 1.4. Professional profiling tools are much more powerful and reliable. LTM was only developed because we could not suffer the overhead of a full blown memory snapshot algorithm. Note that the newer Java 5 offers better ways to collect the memory information either by using JMX or agents and JVMTI.

References

• H.M. Kabutz, Hooking into the shutdown call, The Java Specialists' Newsletter, 2001.
• R. Shaham, E. Kolodner, M. Sagiv, On the Effectiveness of GC in Java, ISMM, 2000.
• J. Shirazi, K. Pepperdine, Eye on performance: Profiling on the edge, 2004.
• Sun Microsystems, Tuning Garbage Collection with the 1.4.2 JVM, 2003.

(List of all my publications with abstracts.)