 |
Device Driver
The device driver must be loaded prior to data
collection. The device driver acts as an interface between the Alpha
performance counter hardware and the daemon process. It services
interrupts from the performance counters, and on each interrupt
records the process id and program counter value for the interrupted
program. These program-counter samples are buffered in the kernel
until they are extracted by dcpid.
Determining Loadmap Information
On OpenVMS, dcpid determines which executable images are loaded in each process and
where they are loaded. Pathnames
for images are stored with profiles so that the analysis
tools can quickly find the images associated with each profile.
- For OpenVMS Version 7.3 and later, a modified version of the image
activator informs the daemon of new image activations (such as a new
process startup, a new image within a process, and so on). The information provided by the image activator to the
daemon includes the pathname of the image being loaded, the
process it is loaded into, and the address ranges
at which it is loaded.
- For OpenVMS Version 7.2 systems, the daemon is aware only of
images that are active or installed when the daemon is started.
(When the daemon process starts up, it scans all active
processes and their mapped regions to identify the images loaded
in processes that started before the daemon was started.)
The modified image activator ensures
that dcpid
knows about all images loaded into each process.
Building a Profile Database
The dcpid
daemon extracts program-counter samples from the device driver and
stores them in an on-disk database. The database resides in a
user-specified directory, and may be shared by multiple machines.
All samples are organized into non-overlapping epochs, each
of which contains samples for some time interval. A new epoch is
started (and the previous epoch terminated) using the dcpictl
command.
Each epoch occupies a separate directory; each epoch directory
contains subdirectories for each platform sharing the database. (A
platform typically corresponds to an individual host, but can be
configured using the file hosts in the top-level database
directory to correspond to a user-specified collection of machines.)
Each platform directory contains files with profile information,
typically one file per image. See dcpiformat
for details of the file format.
Samples are buffered in the device driver and in dcpid.
Buffered samples are flushed out periodically and also when an epoch
is terminated. To ensure consistent results, the analysis tools
should be run only on a completed epoch.
The dcpictl
command can be used to control dcpid.
It provides commands to terminate an epoch and begin a new one; to
shut down monitoring; to flush all buffered samples to the on-disk
database; and to inform dcpid
manually about an image loaded into a process. (The latter is useful
only in unusual circumstances; see dcpictl
for details.)
Analysis Tools
During an epoch, samples are collected for all running images,
including all applications, shared libraries, and the kernel. There
are several ways to analyze the profile data for an epoch, from a
coarse-grained accounting for each image to a fine-grained analysis
of each instruction. Output from the tools ranges from a simple
prof-style listing of time spent in each image to basic-block
flowgraphs of each procedure annotated with information such as
sample counts, the average number of cycles taken by each
instruction, and the possible causes of stall cycles.
- At a coarse level of detail, dcpiprof
shows the time spent in any set of images active during an epoch.
This time can be broken down either by image or by procedure
within each image if symbol information is present.
Note: Symbolic information is created for a program if the program is compiled with
the /DEBUG qualifier, and if the program is linked with the /DEBUG or /DSF qualifier. If the /DSF qualifier is used
to link the program, symbolic information is available if either of the
following is true: - The DSF file resides in the same directory as the program
image
- Logical name DBG$IMAGE_DSF_PATH points to the directory in which the
DSF
file resides.
- At a fine level of detail, a basic-block flowgraph can be
produced for one or more procedures, showing a control-flow graph
of the machine instructions in each procedure annotated with
sample counts for each instruction, the source code associated
with each basic block, and an analysis of stall
cycles for each instruction and the reasons for each stall.
- dcpicalc
produces a control-flow graph with the execution frequency of
each basic block, the average number of cycles taken by each
instruction, the possible reasons for each stalled cycle, and a
summary of how time was spent in the procedure.
- dcpi2ps
takes a control-flow graph from any of the tools above and
produces a PostScript file for viewing or printing.
- dcpilist
lists the contents of a procedure annotated with samples collected during profiling for each line of code. The listing can contain
either machine instructions, or source lines, or both.
- dcpiwhatcg
produces a program-level (that is, entire image, not just a single
procedure) summary breakdown of where time has been spent (percent
of cycles spent in, for example, memory delays, static stalls,
errors in branch prediction, and useful execution).
- dcpidiff
compares sets of profile data. dcpidiff
compares two sets of profiles for a single procedure, highlighting
basic blocks or source lines with the largest differences.
- dcpicat
prints the contents of one or more profile files in an ASCII
format. This is most useful to people debugging the Continuous
Profiling Infrastructure.
Dynamic Code Analysis
Applications, most notably JAVA, create code at run time and
execute it. This dynamically created code is also generally
executed in run-time created data zones. PC samples collected
by DCPI for such code does not map to any existing image.
In
addition, detailed analysis of unknown samples is impossible
since there are no existing source files and no persisting image
code sections.
DCPI for OpenVMS provides routines that applications
such as JAVA or Oracle's RDB Database can use to notify DCPI of certain important
events pertaining to the classification and analysis of dynamic code.
Note that the
application has to link in the DBG$DYN shareable image. DBG$DYN provides the
routines the application can use to identify
dynamic code with the daemon (through mailbox
messages). The daemon in turn uses that information to create
internal mappings and external pseudo-image files in a database
subdirectory (for example, MYDISK:[DCPI.DB.DYN]). Those pseudo-image
files persist and are used later by the analysis tools.
|
