HP OpenVMS Systems

Continuous Profiling Infrastructure

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training


» Home
» What's New
» Install Software
» Documentation
» Publications

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

DCPI Documentation

» detailed descriptions of the commands for DCPI for OpenVMS.

The Compaq (formerly Digital) Continuous Profiling Infrastructure (DCPI) system permits low-overhead continuous profiling of all executables, including the kernel. It is based on periodic sampling using the Alpha performance counter hardware. Profiles containing samples for each executable image (including shared libraries) are stored in a user-specified directory.

Tools are provided to analyze profiles and produce a breakdown of all cpu time by image, and by procedure within images. In addition, detailed information can be produced showing the total time spent executing each individual instruction in a procedure. Additional analysis tools also determine the average number of cycles taken by each instruction, the approximate number of times the instruction was executed, and the possible reasons for any cycles spent stalled not executing instructions (for example, waiting for data to be fetched from memory).

The material below provides an overview of the system, including examples of its use. Detailed descriptions of the DCPI for OpenVMS commands are also available; they give more information about each program in the system, including all command-line options, limitations, and known bugs. The overview below will help you get started using the system, but we recommend that you read all the command descriptions as well.

System structure

At a high level, the Continuous Profiling Infrastructure consists of the following pieces:
  • A device driver that services interrupts from the cpu performance event counters, recording program-counter samples. The device driver must be loaded prior to data collection.  (This is done automatically when you install DCPI; you must run SYS$STARTUP:DCPI$STARTUP.COM when you reboot.
  • A daemon process and a tool to control it. The daemon extracts samples from the driver and builds an on-disk database organized by executable image.
  • A collection of tools that analyze profiles and their associated executable images, producing summary output in several different forms and at several different levels of detail.
  • A shareable image, DBG$DYN, that can be linked with application images. DBG$DYN provides an interface to the DCPI daemon to support profiling of dynamically created code.

System components

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.


When applications such as JAVA or Oracle's RDB Database start up, they must call routine DBG$DYN_BEGIN to allow the DCPI daemon to set up relevant structures and create a pseudo-image file for the application. When data collection is complete, this image file will contain any dynamic code and DST sections that the application  created.

Note that this interface requires that code segments and Debug Symbol Table (DST) records be created within specified virtual address ranges. The DCPI daemon is supplied these ranges via the call to DBG$DYN_BEGIN. If code segments are executed outside the code range,  DCPI has no way of identifying them. If a code segment is generated within the code range but no corresponding DST records were created within the DST address range, DCPI will be able to associate only that segment's samples with the image that was generated by the daemon, and not the particular code section within that image. This means that for any meaningful analysis, DST records must be created for every new section of code.

New address ranges

It is possible that at some point during its execution, an application will run out of room in either its code or DST spaces in memory and will need to create additional ones. To allow for this, a routine called DBG$DYN_ADD is provided. Each time a new space in memory is allocated for either code or DST records, DBG$DYN_ADD must be called to let DCPI know about it. This means that the simultaneous use of multiple code and DST areas is supported. However, note the following:
  • There is no guarantee when DCPI will read the memory segments.
  • The application must call DBG$DYN_BEGIN before any code is executed dynamically.
  • The application must write DST records starting at the beginning (low address) of its address range and grow toward higher addresses without any holes in the section.
  • The portion of an address range not containing code or DST records should be zeroed out.
  • The application must not make modifications to code segments or DST sections once they have been written.

Ending execution

When the application no longer intends to generate new code, it must call DBG$DYN_END give the daemon the opportunity to write out any code segments and DST records that have not yet been written to the image file.

Command descriptions

Detailed descriptions of the commands for DCPI for OpenVMS are available.


Many of the command descriptions have detailed examples showing how to interpret their output.

You can also refer to an example of the interaction between DCPI and an application that executes code dynamically.


  • DCPI requires an OpenVMS Version 7.2 or later system.
  • Image activator hooks are available only when you install DCPI on an OpenVMS Version 7.3 or later system.
  • Support for CPU transitions (Galaxy support) during DCPI sampling is available only when you install DCPI on an  OpenVMS Version 7.3 system (or later) with the following patches installed:
    • VMS73_UPDATE-V0100
    • VMS73_SYS-V0300
  • DCPI is most robust when installed on an OpenVMS Version 7.3  system with the following patches installed:
    • VMS73_UPDATE-V0100
    • VMS73_SYS-V0300