Java Profiler FAQ - JProfiler

How does a Java profiler work?
What's the difference between instrumentation and sampling?
What's the difference between dynamic and full instrumentation?
What's the difference between "elapsed times" and "estimated CPU times"?
Do I need more memory to profile my application?
How do I profile servlets and Java Server Pages with JProfiler?
How do I profile applets with JProfiler?
How do I profile my application server with JProfiler?
Can I attach JProfiler to externally started applications?
How do I find a memory leak?

How does a Java profiler work?

A Java profiler uses a native interface to the JVM (the JVMPI) to get profiling information from a running Java application. The native library is loaded and initialized by adding a special directive to the command line (-Xrunjprofiler). As your application runs, the native library receives various types of events from which it builds its profiling database. JProfiler's GUI frontend connects to the profiled application through a socket and queries the profiling database according to your selections.

 

What's the difference between instrumentation and sampling?

For CPU profiling, there are two fundamentally different ways to collect information:

• When sampling, a timer thread suspends all threads periodically (typically every 10 ms) and looks up the call stack of each thread. Each period is booked to the "least common denominator" of two subsequent measurements. While sampling is very fast, it has a shallow information depth because of its coarse resolution and the inability to provide an invocation count. Sampling is ideal for fast bottleneck detection.
• With instrumentation, the entry and the exit of each method call are intercepted by JProfiler's agent library. This way, an accurate measurement of the elapsed time can be made. If you have selected "estimated CPU times" in the sessions settings, the elapsed times are subject to a correction algorithm (see below).

 

What's the difference between dynamic and full instrumentation?

Full instrumentation means that each and every method call that is made in the JVM is reported to the JProfiler agent library for separate measurement. Because usually the majority of all classes is filtered to hide the inner workings of external APIs, the vast majority of these measurements is unnecessary, especially for J2EE applications running in large application servers.

Because enabling full instrumentation makes JVMs quite slow (especially hotspot VMs), ej-technologies has developed the concept of dynamic instrumentation. Dynamic instrumentation works by instrumenting Java bytecode on the fly as the JVM loads classes from external storage. The raw class files are intercepted by JProfiler's native agent library before the JVM parses them. Appropriate bytecode instructions for profiling are added at the beginning and the end of each method as well as around calls into filtered packages. The bytecode modification is done with a C++-port of jclasslib.

What's the difference between "elapsed times" and "estimated CPU times"?

When measuring the duration of a method call, one can either stick with the simple elapsed time, that is the clock difference between method entry and exit, or make the best effort to correct for the multi-threaded nature of the JVM. In the estimated CPU times mode, the data of the thread status sampler and the cumulated CPU time of each thread as reported by the operating system are used to weight all method calls. For both modes, a calibration phase at startup calculates run-time parameters for a self-correction algorithm which account for the times used by the profiling process itself.

 

Do I need more memory to profile my application?

Profiling does need a considerable amount of memory for the profiling database which is kept in memory at all times. If your physical memory is close to the amount of memory used by your unprofiled application, profiling will probably result in high swap activity, the execution speed of your application will deteriorate by a few orders of magnitude and become practically unusable. We recommend to profile on machines that have at least three times the physical memory capacity as the memory consumption of your unprofiled application. If you're short on memory, you can choose profiling settings with low memory overhead as indicated by the memory status bar.

 

How do I profile servlets and Java Server Pages with JProfiler?

JProfiler ships with a bundled servlet container (Apache Tomcat 4.0.6). Just create a servlet session and enter the path to your web.xml.

If you need a different environment, it's easy to integrate your own installation of Apache Tomcat or other application servers with JProfiler (see below).

How do I profile applets with JProfiler?

There are two ways to profile applets:

• integrated by creating an applet session and supplying the file name of an html file containing the html tags of the applet to profile as a parameter. The applet session will use the class sun.applet.AppletViewer (in lib/tools.jar of the JDK) to show the applet.
• in browser by using Sun's Java Plugin. In the Java Plugin control panel (can be started in Windows from the system control panel), the Java runtime parameters on the standard tab must be filled in as described for remote profiling. If you're using a Sun JDK, that means adding:    -Xint -Xrunjprofiler -Xbootclasspath/a:[path to agent.jar]
  Don't forget to add {JProfiler install directory}/bin/{your platform} to the search path for loading native libraries (PATH on Windows).

 

How do I profile my application server with JProfiler?

JProfiler comes with a wide range of application server integration wizards. Just follow the step by step instructions to integrate your own application server. Even if an application server is not supported by the integration wizard, it can be profiled by JProfiler. Just select "Other application server" in the integration wizard and follow the generic integration tutorial. Most application servers can be started and stopped by JProfiler, so you can profile them without invoking them from a terminal first.

 

Can I attach JProfiler to externally started applications?

Profiling externally started applications is generally done by making a copy of the start script (if there is one) and adding the necessary command line parameters (see the help page remote session invocation table) to start the application under the control of JProfiler's agent library. When running the modified startup script, the applications main class is started only after a connection is made with JProfiler's GUI frontend on a specified port. In JProfiler's GUI frontend, you create a remote session which connects on the same port and start it. After a connection is established, profiling continues just as with local sessions.

 

How do I find a memory leak?

The key to finding memory leaks is the heap walker. The heap walker operates on a static memory snapshot that you take at a certain time by clicking on the camera icon which is visible in the toolbar for all memory views. The "Show path to GC root" functionality in the reference graph is the key to finding out why objects have not been garbage collected.