Analyzing an application with JProfiler Tool
JProfiler is a modern and very useful Java tool for analyzing data. It’s dedicated to analyze J2EE, J2SE projects, and can integrate a number of IDE. An equivalent profiler for NetBeans is Jfluid Technology.
JProfiler’s interface is user friendly and very fast in achieving the goal that came from the need to use an analyzing tool, which is, to show the performance statistics about the selected application and the possible leaks.
Current version is 6.0.3 and can be used as a free trial for a determined amount of time.
JProfiler offers a lot of features for an analyst/tester/programmer such as: can detect out the memory overflow,
memory leaks,show the count and size of variables from the application etc.
By default the tool does not track the creation of all objects, thus the count of them is updated as the application is used. It can also keep statistics on Garbage Collected(GC) objects and in the view can be chosen to see only live objects or GC objects or both .
For the non recorded objects, JProfiler does not know about the class name and so, the monitor views and graphs are influenced.
To recognize a memory leak in the application go to “VM Telemetry Views” and if there are linear stripes, then it means that in the application some instances use a lot of memory.
If at the start you have a decent count of instances and on executing a command the number goes though the roof, then there is a “time bomb” problem. It will crack and it all depends on when. An optimization is in order, try to reduce the number of instances, size. Maybe some objects that are kept alive should be freed by the GC. To detect these objects you can go to “Heap Walker->Biggest Objects” and see for yourself the tree with the details. There you will have specified the packages and size. See picture below:
One of the interesting features of JProfiler is the “Heal Walker->References”. In the documentation of the tool it says “Here you can find out how single objects are referenced and why they’re not garbage collected.” Choosing an object from the (for eg) Classes tab, double clicking on the one you are interested to analyze more and a new object will be created for this. This object will contain all the allocation spots in the current object set. Now, in the References tab you are offered the option to search for paths to the GC roots. You can choose to show in the view a single root, a specified number of roots or all of them. See picture below:
Anywhere in the shown chain can be looked for a potential memory leak.
This type of analyze is very important. We want everything to run faster better and to use as less as possible from any type of resource.
I found this small article about CPU profiling that is used at Google(http://goog-perftools.sourceforge.net/doc/cpu_profiler.html).
Back to CPU profiling using JProfiler (the CPU usage is disabled by default) :)
An important feature is the wall clock time, which is the duration between the start and end of a method measured in time with a clock. Take in account that this timer is not actually the time spent by the CPU on the method. The Operating System Scheduler , the documentation states, can interrupt the execution of a method as many times as it wants and perform other tasks.
This made me wonder on how accurate is this, or how can you trust the end result of timing, but reading some more about it I found out that the actual time on the method is called CPU time. So there can be differences between CPU time and walk clock time, and remember to read the CPU time. To “enable” the CPU time(the wall clock is default) you have to edit the Profiling Settings and change the Measurement type. See picture below:
Not tested but documented, it seems that Operation Systems offer different timers with difference performance rate. “For example, on Microsoft Windows, the standard timer with a granularity of 10 milliseconds is very fast, because the operating system “caches” the current time. However, the duration of method calls can be as low as a few nanoseconds, so a high resolution timer is needed. A high resolution timer works directly with a special hardware device and carries a noticeable performance overhead.”
– JProfiler official website