The next Java profiling tool I looked at, and which I think I’ve settled on, is aptly-named Eclipse Profiler Plugin (EPP). Unlike the Extensive Java Profiler (EJP), this one’s truly an Eclipse plugin. Like EJP, the EPP lets you view the per-method CPU time (and other measurements). The difference is that it’s done dynamically; no more waiting for the job to finish, dumping a huge log file, and then using a separate postprocessing tool to analyze the results.
Something that both of these tools seem to be missing, and which I would like to see, is an API that gives me a lot tighter control over when profiling is turned on or off. The EPP does give some control over filtering out classes from certain packages, and turning profiling on and off when you enter or exit one specific method, but I’d like to see more done in this area. Another thing I’m looking for is better tutorial documentation about how best to use such a profiling tool. It’s imperative that the documentation tell you which button to press to trigger a certain action, but it’s more important in my mind to give guidelines about when certain profiling tools are useful and how to get the most benefit from them. A lot of times I find that I’ve run the test, am looking at the profiling results, and still am no closer to understanding where all the time’s going.
The last tool I looked at, and one which I’m still interested in, is JFluid from the Sun Research Labs. This one’s a little more invasive in the sense that you’re actually replacing the stock Java 1.4.2 Hotspot VM with a modified version from the JFluid project. This modified JVM supports dynamic bytecode instrumentation, which means that you can actually change the parts of the program that are being profiled while the program’s still running. Furthermore, by selectively instrumenting certain parts of the code (while leaving others alone) you don’t suffer the performance hit that many other profiling tools impose when they effectively instrument every method call.
JFluid also has some nice tools built in to its GUI for visualizing the heap usage and “object liveness”, i.e. the numbers of objects which survive over successive generations of garbage collection. This is something I didn’t see in the other profiling tools, and it provides an especially useful way to detect memory leaks. If some object(s) survive for a large number of generations, it is quite possible that you’ve got a memory leak. JFluid can tell you where those objects were allocated to give you a head start on finding those potential leaks.