The Cure for Ailing Java
JProbe ServerSide Suite 2.5
By John Pearson
When I was in my early 20s, I spent two delightful years in Chile. Though I had taken Spanish, I still encountered strange words. One of the words I remember was mentolato, which describes a jack-of-all-trades. When I asked what it meant, I was shown a jar of Mentholatum and told that it was used to make everything better: colds, coughs, cuts, cold sores, and more.
KL Group's JProbe ServerSide Suite is Mentholatum for Java. It can fix a variety of ailments in your Java code. The Suite includes three separate tools: the Performance Profiler and Memory Debugger, Coverage, and Threadalyzera thread analyzer. You can start these tools individually or use the JProbe LaunchPad. You can use several of the tools at once, or even purchase them separately if you don't need them all.
More importantly, you can have several instances of each program running at the same time. So you can run and analyze multiple applications, servlets, or applets simultaneously. This lets you check the system while it's running and watch the interaction between pieces, rather than having to run an applet in a test frame and hope your testing is accurate.
There are common threads running through all these tools. Each has the ability to configure which classes the tool will include or exclude. This lets you zoom in on the areas that interest youa real time saver. You can also specify which Java VM the tools will use, and when to take snapshots (collect data regarding the status of the program during execution). I like the snapshot approach. It lets you take time slices of program execution and to see what happened at critical junctures. Similar to reviewing a black box on an airplane, this method is especially handy with the Profiler.
JProbe Profiler and Memory Debugger
By definition, profiling is a means of locating performance bottlenecks in your programs so you can remedy them. JProbe's Performance Profiler gives you just thatin both a visual summary and a detailed statistical format.
When you run a program through the Profiler, it takes periodic performance snapshots of your program (you can also take them whenever you want by clicking on a camera icon in the Profiler window). A Call Graph window appears inside the Profiler instantly. The Call Graph contains two panels: a graphical tree on the top and a Methods Detail list below. The tree represents the program's branches, from the root through the main, to the other methods of your program. The view color-codes each node on the tree and identifies how much of your resources the associated node uses. This lets you identify at a glance areas that demand the most attention.
Below the hierarchy tree is a Method Detail panel that includes the statistics on number of calls, cumulative time for each method, average method time, and several other items. Here you can read the exact numbers for various nodes on the tree. If you need further detail, you can click again on these general methods, and a finer level of detail appears in another window. By checking both of these windows, you can quickly get a feel for where your program is spending its time and isolate problem areas by method name.
From the Method Detail panel, you can also select a Source view, which will bring up your original Java code and give you statistics, line by line, as you scroll through the code. All of these features combine to make the Profiler an excellent tool to improve the performance of your Java code.
Figure 1 shows how Profiler tracks object, method, and heap usage.
The Performance Profiler is just one half of a one-two combination. The second half is the Memory Debugger. The Memory Debugger runs whenever you're profiling Java code. It displays the Runtime Heap Summary window. This window, like the Profiler, has two panels. The top panel has a graph that continually displays the available and allocated heap space. The bottom panel (the Instance Summary) tracks object creation and deletion.
By monitoring the Runtime Heap Summary window, you can compare the expected usage with the actual usage to see if the two agree. If they don't, you can investigate further by looking at the Instance Summary panel.
The Instance Summary contains the names of the objects that have been created, a count for each object, and the amount of memory used by that object given in both amount and percentage of total. This chart can help identify objects that remain in memory when they're no longer needed or objects that use more memory than expected.
I must add, that when I first tried the Memory Debugger, I expected a debugging capability that could view and edit memory values. This Memory Debugger doesn't do that, it assumes that you will use other methods for that type of debugging. What this debugger does might best be defined as Memory Allocation Tracking, which makes this tool a very useful enhancement to the Profiler.
JProbe's Coverage tracks the lines of code that were executed in your programs. This is a great way to check which modules, lines of code, and programs have or have not been tested.
When you run a program, the tool monitors its progress, class by class, in a Coverage browser window. When you take a snapshot (again, you can do this by clicking on an icon at any time), the results are initially grouped by the entire classname and you are provided with the following data:
- the number of calls the program made to the module,
- the number of methods the program hit or missed,
- the number of lines hit or missed,
- the total percentage of hits and misses.
Coverage maps each line and keeps track of it, which makes it easy to define the progress of testing.
There's also a Source window that shows the program source code. It's also linked to the other windows, so if you click on a line that appears in one of the other windows, the Source window will immediately pop up. The Source window uses blue text to identify the tested lines and red to indicate the lines not analyzed (the colors aren't customizable).
My favorite tool of the bunch is JProbe's Threadalyzer. Multithreading is one of the most challenging and frustrating aspects of programming. Although Java supports multithreading better than many other languages, when there are problems, things still come tumbling down.
Threadalyzer monitors thread execution as the Java VM runs and can pinpoint the cause of deadlocks, potential deadlocks, and data races. After identifying any of these problems, Threadalyzer tells you where and what the problem is so you can fix it.
I ran Threadalyzer several times and discovered that JProbe not only identifies where these problems occur, but it can also analyze your code and locate potential problems. I tried it on various pieces of code and it caught the errors I threw at it every timeand in the right places. I like that!
When you run Threadalyzer you can select which conditions it will monitor, how to respond to them (such as exiting when a deadlock is detected), and how long to wait until the program considers a thread stalled. You can also select which classes to exclude from analysis.
Visualizer tracks the results. This is the visual interface that runs concurrently with your program. It shows a list of messages for each problem. This list contains the class name and line number, so you can find offending lines in your code and take a closer look. I was really impressed that some of the messages said more than, "There's a problem here!" See
Example 1 for some typical messages generated by Threadalyzer.
These messages let you exactly pinpoint the location and culprits in your code. Like the other tools, Threadalyzer can take snapshots at any point in time, save them, or print the results for later examination.
This version of JProbe also supports server profiling. You can profile and test Enterprise JavaBeans (EJBs), servlets, client-side applets, and applications wherever they reside. Remote profiling works well too.
When you install JProbe, you can select from one of the supported servers. JProbe supports IBM WebSphere, BEA WebLogic, Java WebServer, Live Software JRun, and Sun ServletRunner. After you make your selection, the installation program will automatically configure your server to work with JProbe.
I use Visual Café by Symantec 3.0. When I installed JProbe, it automatically integrated itself as a menu option in my IDE. This provided instant access to all the suite tools. Now it's much easier to get started and keep track of the tools. Also, when I found problems in a particular class, I was already in the right environment to test it. JProbe is also fully integrated with IBM's Visual Age for Java (versions 2.0, 2.5, and 3.0).
Unfortunately, JProbe doesn't have any additional security capabilities aside from those provided by the operating system. For example, if you're running under NT you'll have to use NT security to prevent unauthorized users from running JProbe.
JProbe will run under SPARC Solaris or Windows environments (support for some of the Linux/UNIX flavors is being contemplated). The Solaris requirements are 96MB of RAM, 70MB of disk space, the Solaris 7 or 2.6 OS, and an UltraSPARC processor. The Windows world requires 64MB of RAM, 40MB of disk space, and a Pentium 133 or faster. For Java 2 applications, you'll also need JDK 1.2.x (or JRE 1.2.x).
There are two versions of JProbe. The Developer version is for stand-alone systems. The ServerSide (or Professional) version is for those who need to work with servlets or server-based applications. You can also purchase individual components–but the suites are a better value.
KL Group has worked very hard to establish JProbe as the premier suite of Java analysis tools. The strong visual interface, extensive integration, and ease of use make it the one to consider. It may not fight colds, but it will help speed up, clean up, and unlock your Java code to optimize it and keep it running.
John develops software using Java and a number of visual development tools. He has contributed to several magazines including JavaPro, Visual Basic Programmer's Journal, and Visual Developer.