Introduction to JProfiler

There are basically 3 types of profiling:

  1. time – measures the execution paths of your application on the method level
  2. space – gives you insight into the development of the heap, such as which methods allocate
    most memory
  3. thread – these analyze thread synchronization issues

Some traditional profilers dump their profiling data after the application exits. JProfiler is an interactive profiler however, and it combines all the 3 above profilers into a single application and correlates the data from all 3 domains in real-time.

Before Java 1.5 the SDK offered a Java Virtual Machine Profiling Interface (JVMPI) but this varies between JVMs, cannot run with modern garbage collectors and has problems profiling large heaps. With Jave 1.5 the JVM Tool Interface was added to overcome these problems and JProfiler utilizes both.

These interfaces are event-based, allowing the profiling agent to register handler functions for different events. Disabling some events is important for reducing profiler overhead and JProfiler has object allocation recording switched off by default. When you enable allocation recording in the GUI the agent tells the JVMPI/JVMTI interface to enable the handler for object allocation events.

The Information vs Runtime Overhead Trade-off

Profiling adds overhead to the profiled application, causing it to run more slowly and consume more memory. If alot of objects are created and lots of method calls occur while the profiled application is running then this creates a significant overhead since the profiler has to do alot of record-keeping operations to keep track of all these operations in its internal data structures.

Optimizing the Data

Too much detail can make it more difficult to track the operations your interested in profiling. For example, most often you are not concerned at all with the internal call tree of framework classes, but are interested in what your own classes are doing. When you have no control over the implementation, the internal call structure is not very helpful and is likely clutter that you dont need. You can stillrecord this data and filter it out using the view filters eg. the CPU views allow you to remove call structures that do not match your filter from the tree, but this data is still being recorded and causing an overhead so its better practise to not record it.

When an application starts up alot of objects are created that you probably dont need to profile so its best to leave object allocation recording switched off during startup, the same goes for profiling method calls, or “CPU profiling” – this both increases performance and keeps the generated data focused on what your mainly interested in.

Some information, such as the references between objects as well as the data in them is not available from the events fired by the JVMPI/JVMTI interfaces. To get this level of detail on allobjects on the heap you need to have the profiling agent trigger a “heap dump”. This command takes a snapshot of the heapwalker.

Starting the Profiler

The profiling agent has to be started at the beginning of the JVM startup. This is done using JVM parameters eg. for Java 1.5+:


The JProfiler GUI is started separately and runs in its own JVM, rather than being started by the profiling agent. This is so as not to disturb the profiled process and also to facilitate remote profiling. The GUI and agent communicate via a TCP/IP network socket – this is the case even with local sessions. The profiled data resides internally in the agent and only a subset is transferred to the GUI otherwise the data load on the socket would be too great for effective profiling, especially when the agent and GUI are remote from each other.

Configuring the Profiler

Successful profiling is about choosing the right profiling parameters that dictate to the agent what events to respond to and capture data for. There are filters that control the extent recorded call tree and these are configured in the GUI. Since these parameters are required at startup, the profiling agent stops the JVM and waits for a connection from the GUI before the profiled application is allowed to start.

Profiling Settings

These control the way profiled data is recorded and cannot be changed once a profiling session has begun.

Leave a Reply

Your email address will not be published. Required fields are marked *