Some time ago, I created the “TopThreads” plugin for JConsole, that helps you to determine why your Java application is causing such a high CPU load, by showing the most busy threads in your application and giving you the opportunity to inspect thread-stacktraces at the same time. It turned out to be quite usefull and from the responses I got, I can tell people find it still usefull today. A few days ago, I released a new version of this plugin, with one very usefull new feature: CPU usage.

Top thread?

If you’ve used the topthreads plugin, you probably seen this before: suddenly, a thread that is not supposed to be very busy, pops up at the top of the table with usage figures in the 90’s. You wonder WTF is going on, that this thread is taking so much CPU power, until you realize that this figure is only relative to the rest of the application threads. And if the application is hardly doing anything, threads that do a little more than anything might get alarming high figures (and red color). After i ran into this pitfall a few times, i decided i needed to know an absolute usage figures too.

If you enable this feature (settings -> show process cpu usage too), the top row of the table shows the CPU usage of the process as a whole. This is simply the sum of the CPU usage of all threads. The percentage shown in this row however, is the percentage this process is using the CPU, which should be approximately the same value a process viewer like top, Activity Monitor or the TaskManager would report. Although this is not always the case – more about that in a minute – it’s at least a good indication whether the process is busy or idle. And even though it may not always be as acurate as i would like it to be, it proved itself to be proficiant to help me avoid confusion.

The usual suspect: the garbage collector

In normal situations (whatever that me be… ), the CPU usage figure is approximately the same as the figures other tools report. However, especially when the process is very busy, the CPU usage shown is far too low. After some testing, i’m rather confident that this is mainly caused by the garbage collector. As it turns out, TopThreads does not get information for all the JVM threads, which can easily be verified by comparing a thread dump with the thread listing in JConsole. For example, threads that never appear in JConsole (not in the TopThreads tab, but neither in the JConsole thread view) are the “Low Memory Detector”, compiler threads (HotSpot), “Signal Dispatcher” and “Surrogate Locker Thread (CMS)” and the garbage collector threads (the mark-and-sweep thread and the parallel gc threads). I can image that some of these threads can put a lot of load on the CPU when the application is very busy. And one thing is for sure: the cpu cycles that are taken by these threads are not counted in the totals that the TopThreads plugin computes, simply because it doesn’t know about these.

Despite these shortcomings, i find the new feature quite usefull myself. Let me know what you think.

Other improvements in this release:

• the initial poll time is not fixed to 10 seconds, but depends on the (initial) number of threads. For small apps, the updates will be much more frequent.
• there are more preferences to set and these are moved to a separate settings dialog. Settings are stored using the Java Preferences API.
• improved stacktrace panel behavivour, including automatic scroll to the top.
• better handling of security exceptions, that might occur when connecting to a remote VM.

Please let me know what you think, feedback is always welcome!