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 :-
-
Individual object allocations
Each individual allocation and release is tracked against the allocating
object. Thus if there are allocations against the Object class they will
be tracked and recorded against this class in the allocation report.
-
Object array allocations
Each individual allocation is tracked and logged against a Object Array
class. Thus if an array of Object's is allocated the allocation will NOT
be tracked against the Object class but against the Object Array class.
(This is due to a limitation in the JVMPI implementation which does not
identify a class for object array allocations. It may be remedied at some
time in the future.)
-
Primitive data type allocations
Each individual allocation is logged and tracked against an Array class
for the primitive data type. Thus arrays of shorts are tracked and recorded
against the Array of Short class, whereas arrays of Ints are tracked and
recorded against the Array of Int class.
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.