Profile

Enter the details for a profiling run and generate profiling information. The amount of overhead imposed by the profiler varies according to the type of profiling and the nature of the application. My measurement indicates that each option imposes a CPU overhead of the order detailed with each option.(N.B. These overheads are not quite cumulative, ie doing a method profile and a synchronisation profile in the same run will not yield an overhead equal to the sum of the two overheads, it will be somewhat less. This is because some of the overhead is shared when multiple profiles are generated.) The memory overhead of each option is negligible apart from the Memory Allocation option, in which case the overhead is typically about 1/3 of the memory required by the application.

Trace Options

There are four different categories of information on which information may be generated :-

Heap Profile (Heavy-weight) - CPU overhead 1000%

Every memory allocation of the target application is collected. When the system performs garbage collection, all memory releases are tracked against the original allocations and allocation information is attached to the garbage collection report. Note that the profiler measures allocation instances as follows :- Since Object arrays are not currently apportionable to their class, the information on allocations is compromised. However, the information on individual object types is still useful. The tracking of individual object allocations allows much more detail to be added to the garbage collection report.
Detailed information on the use of individual classes is added to the final GC report of the profile. This information consists of a list of object types, ordered by current live memory use,  with the number of allocation sites used to allocate the object and the individual utilisation for the top 20 sites along with a call trace for the site.
Use
If you want to know in detail what your application is doing with memory, use this option. Please note that the amount of information collected by this type of profile has a serious impact on garbage collection duration, resulting in extremely distorted GC timing.

Garbage Collection (Light-weight) - CPU overhead 20%

Each time the JVM performs garbage collection, a limited report of memory use is reported.
Use
Use this option if you think that your application is using more memory than you would expect and you need to have a rough assessment of the amount of memory used and available from the heap. If you think that you have a serious memory problem, then you need to use the Memory Allocation option to do more detailed analysis. (N.B If you want more information than is generated by this option, but don't want to do a full memory allocation run, try using the -verbose:gc option when invoking java. You get quite a lot of detailed information on the efficacy of each GC invocation and the CPU overhead is identical to this option.)

Thread Synchronisation (Light-weight) - CPU overhead 15%

Each time a thread waits to gain access to a monitor, jProf logs the class of the target object and the wait duration.
Use
Use this option if you are trying to remove synchronisation bottlenecks from your application.

Method Usage (Medium-weight) - CPU overhead 250%

Method utilisation information comprising of CPU use, elapsed time, invocation count and method invocation path is captured for all threads.
Use
Use this option if you are trying to improve the efficiency of your application processing and need to identify CPU utilisation. Processing bottlenecks are clearly identified and the call trace assists in identifying where best to attack the processing problem.


In addition to the four main options listed above, there are a couple of fine-tuning options which may be used to control the method profiling option.

Core Classes

By default, jProf does not provide profiling information on the java.* and sun.* classes. If you wish to collect information on these classes, then select this option.

Method Sampling

By default, jProf monitors every single method call made by your application. If you want to speed up the profiler (at the cost of losing some reporting accuracy) then use this option to enter a sample frequency. The number that you enter will be used by jProf to control the number of methods sampled, for instance if you enter 2, then every second method call will be monitored. This option reduces the accuracy of the generated profile since the method utilisation counts and CPU use times will be distorted, however it can be useful if you need to get a rough idea of what is going on and don't have time to wait for a comprehensive method profile to execute.

Generate HTML

By default, jProf will automatically process the XML generated by profiling and create the HTML output for viewing. You can turn this option off using this menu and process the XML later by opening the XML file.


File Menu

Open

You can open the results of previous profiles by opening the <profile name>.html file. For instance, if you saved a profile under the name test1 you would open the Results/test1/test1.html file. You can also use this option to open an XML file, this will cause the profiler to automatically generate and display the HTML for this profile.

Exit

Leave the profiler. Don't use this option when profiling a target as it will leave the target running on your machine.

Input

Directory

Specify the working directory for the application to be profiled. Specify the path in a platform dependant fashion. e.g on Solaris the path could be /home/garyp/java or on NT \winnt\profiles\garyp\java.

Command

Add any invocation parameters required by the application here. (N.B. On Solaris the profiler automatically adds the -native flag to the command line.) For instance, the DipAdvisor application uses the following command line java -cp DipAdvisor.jar DipAdvisor. To profile this application enter -cp DipAdvisor.jar DipAdvisor in the command field.

Target

The target button displays a file chooser dialogue. Choose a jar or class file and the Directory and Target fields will be completed with the correct values to invoke the chosen target. Note that you may still have to add application specific parameters to the command line to enable the target to execute; e.g. security manager specifications, CLASSPATH additions, etc...

Reset

Clear the Input and Console panels.

Run

Start profiling the target. When the profiler is running this button changes to stop and a profile can be halted. At certain stages of the profiling, this button will become inactive because the profiler cannot be intterupted.

Output

The profiler generates an xml trace file in the <jProf installation>/xml directory. The name you enter in the output entry field is used as the base for the name of the output file and .xml is tagged on to the end of the name.

Console

The console text box displays the standard output of the application being traced. (N.B The output is truncated every 500 lines.)

HTML

Depending on the profiling options chosen, a series of different HTML pages are generated. A tab is automatically added to the GUI following a successful profiling run. This tab contains the "home page" of the latest run. You can navigate among the generated results using this tab as a "browser". Alternatively, you can open the generated results in the browser of your choice.

Charts

As an alternative to reading the HTML output, certain results are summarised and displayed as charts. The Charts tab contains a simple interface which can be used to view various results as line, bar or pie charts. The charts may be resized using the split pane or by resizing the entire GUI. It is possible to zoom in on areas of line and bar graphs by holding in the shift key and rubber-banding the area of interest.  Also, holding down the Ctrl key and dragging the mouse about in the chart will move the origins. The 'R' key resets the chart to the default view.

Help

This tab, containing help.