Offline profiling and triggers
In the screencast below, I explain how to automate profiling with offline profiling and triggers, so that you do not have to use the JProfiler GUI for profiling and can analyze profiling results later on.
Category: jprofiler
Cumulating and filtering monitor events
In the screencast below, I explain how monitor events in the locking history graph can be cumulated and how you can select monitors and threads of interest.
Monitor events versus locking situations
In the screencast below, I discuss cross-links between the various monitor views. The profiled test program is the same as in the screencast on Locking graphs in JProfiler.
Locking graphs in JProfiler
In the screencast below, I present some of the features in the locking graphs that have been introduced in JProfiler 6.
The test class that is profiled in this screen cast is given below:
public class MonitorTest {
// The only monitor that all threads are blocking or waiting on
private static final MonitorTest monitor = new MonitorTest();
public static void main(String[] args) throws InterruptedException {
// All threads execute this runnable, each thread acquires the
// monitor, works for 3 seconds and then waits on the monitor
Runnable runnable = new Runnable() {
public void run() {
synchronized (monitor) {
try {
// Instead of doing any real work, the thread just
// sleeps for 3 second
Thread.sleep(3000);
monitor.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
};
// 3 threads are started with an offset of 500 ms
new Thread(runnable, "Test Thread 1").start();
Thread.sleep(500);
new Thread(runnable, "Test Thread 2").start();
Thread.sleep(500);
new Thread(runnable, "Test Thread 3").start();
// After 20 seconds, all threads are woken up and the test class
// terminates
Thread.sleep(20000);
synchronized (monitor) {
monitor.notifyAll();
}
}
}
Allocation recording explained
In the screencast below, I explain allocation recording in the dynamic memory views in JProfiler.
Thread states in the CPU profiling views
In the screencast below, I explain the thread status selector and the different threads states in the CPU profiling views.
JProfiler’s IDE integrations
For The IntelliJ IDEA integration, this screen cast is outdated, please watch the more recent version instead.
In the screencast below, I explain the benefits and the usage of JProfiler’s IDE integrations.
The different references views in the heap walker
This screencast is outdated, please watch the more recent version instead.
In the screencast below, I explain the different reference views in the heap walker.
Finding a memory leak with JProfiler (old)
Object counts in dynamic memory views and the heap walker
Often the question comes up why there are larger object counts in the dynamic memory views than in the heap walker. The simple explanation is that the dynamic memory views show all objects on the heap – even those that are unreferenced, while the heap walker only shows objects that are strongly referenced.
Here, for example, in the “All objects” view, a particular class has an object count of 6741:
In the heap walker, the object count is only 6282:
The difference comes from objects that are not referenced anymore, but that are still on the heap because the garbage collector has not collected them yet. Clicking on the “Run GC” button in JProfiler might collect some, but not all of them, since the garbage collector does not do full collections in modern JVMs. However, when you take a heap snapshot, a full collection is done internally, so you only look at objects that you can actually do something about.
Ideally, we would exclude unreferenced objects from the dynamic memory views too, but this information requires an expensive calculation that can only be performed when taking a heap snapshot.