Updated 2004/11/29

Sun[tm] Studio 10: Performance Analyzer Readme

Contents

  1. Introduction
  2. Starting the Performance Analyzer from the IDE
  3. About the Performance Analyzer
  4. New and Changed Features
  5. Software Corrections
  6. Problems and Workarounds
  7. Limitations and Incompatibilities
  8. Documentation Errors
  9. Required Patches

 

A. Introduction

This document contains information about the Performance Analyzer and its accompanying analysis tools. The performance analyzer and analysis tools include commands for the collection and manipulation of program performance data, a graphical user interface, and a command-line interface, er_print, for the display of performance data. The term Collector is used in this document for the tools that collect performance data and their underlying libraries. These tools are the collect command, the dbx collector subcommands, and the performance data collection features in the IDE.

This document describes the new features and software corrections that are introduced in this release and lists known problems, limitations, and incompatibilities of the Performance Analyzer software in this release. Information in this document overrides information in the manuals of this release.

The Performance Analyzer requires a license for this release. You can install the serial number license for this software by using the snit command to run the Serial Number Installation Tool. For more information, see the snit(1) man page.

Product Documentation

Note - If your Sun Studio compilers and tools have not been installed in the default /opt directory, ask your system administrator for the equivalent path on your system.

 

B. Starting the Performance Analyzer from the IDE

To start the Performance Analyzer from the IDE, do one of the following:

To open the Collector window from the IDE, do one of the following:

 

C. About the Performance Analyzer

This release of the Performance Analyzer is available on the following platform:

The program performance analysis tools collect statistical profiles of a program's performance and trace calls to critical library routines, and display the data in tabular and graphical form. The collected data is converted into performance metrics. Metrics can be viewed in tabular form at the level of the load-object, function, source line or instruction. The tools provide a means of navigating program structure that is useful for identifying functions and paths within the code that are responsible for resource usage, inefficiencies, or time delays. The Performance Analyzer GUI can also display the performance data in a timeline display.

This release of the Performance Analyzer collector allows profiling of applications written in the JavaTM programming language, using underlying support in the Java virtual machine (JVM). JVM[tm] software versions 1.4.2_02 and later 1.4.2 updates, and 1.5.0, contain this support. It may change in future JVM releases. If you use this release of the Performance Analyzer collector with a later JVM release, the collector may not be able to collect profiling information for applications written in the Java programming language. Sun expects that future releases of the Performance Analyzer collector will be available to support Java profiling under the changing JVM profiling technology.

 

D. New and Changed Features

This section describes the new and changed features for this release of the Performance Analyzer.

Note - If the compilers and tools from this release are not installed in the default /opt directory, ask your system administrator for the equivalent path on your system.

  1. New Supported Platform
  2. Changed Experiment Format
  3. New er_kernel Utility
  4. Extra Precision for Percentage Metrics in Analyzer and er_print
  5. Editing Capability of Experiment Notes File Added to Analyzer
  6. New Options for Display of Function Names
  7. Enhanced Metrics Selection in the Performance Analyzer
  8. Changes in Performance Analyzer Collector GUI
  9. Enhanced Hardware Counter Profiling
  10. New appendfile Option Added to er_print
  11. Default Behavior Changed for er_src
  12. Default location of Java
  13. Extended Options for collect -j
  14. New collect -J Option
  15. Changed Sampling Behavior During Pause and Resume
  16. Name of Pseudo Function Changed for JVM Functions in Java Mode
  17. Names Changed for Subtypes of <Unknown>
  18. Paths of Processed .er.rc Files Now Displayed
  19. Environment Variable JDK_1_4_2_HOME is Obsolescent
  20. Heap Profiling for Java is Obsolescent
  1. New Supported Platform

    The performance tools now support

    • Solaris Operating System 10 on SPARC, x86, and AMD64 based systems
    • Linux on AMD64

  2. Changed Experiment Format

    The following changes have been made to the experiment format:

    • Experiments now have an entry in the log giving the word size of the target in bits.
    • The version number has changed from 9.1 to 9.2. New experiments will not be readable with older tools, but older experiments will be readable using the Sun Studio 10 tools.

  3. New er_kernel Utility

    The er_kernel command collects metrics and generates an experiment on code running in the Solaris kernel. This utility is available on Solaris 10 only, and requires DTrace permissions to allow usage.

  4. Extra Precision for Percentage Metrics in Analyzer and er_print

    The precision of percentage metrics in the Performance Analyzer and er_print has increased from one to two decimal places.

  5. Editing Capability of Experiment notes File Added to Analyzer

    The experiment notes file can now be directly edited in the Analyzer when the Experiments tab is selected. Also a toolbar has been added to the Notes section of the Experiment view that allows the notes to be saved and for undoing or redoing edits since the last save on a character-by-character basis.

  6. New Options for Display of Function Names

    In the Performance Analyzer, a new option for displaying C++ or Java functions in mangled format can be selected using the Format tab in the Set Data Presentation dialog. Also a checkbox gives the user the option to append the shared-object name to the function name for whatever format is chosen for the function name.

    Similarly, in er_print, the name option now takes mangled as a parameter in addition to long and short. The name parameter can be extended, with :soname or nosoname, to add or remove the shared-object name from the display of function names.

    Example:

    • er_print -name long:soname

    The above command will select the long form of the function name including the shared-object name.

    Note that display format of function names will change in subsequent invocations of both the Analyzer and er_print if the format is changed and saved in the Analyzer or directly edited in the .er.rc.

  7. Enhanced Metrics Selection in the Performance Analyzer

    When using the Metrics tab in the Set Data Presentation dialog, an additional row of checkboxes and an extra control button enables the user to select or clear the display of all metrics at once.

  8. Changes in Performance Analyzer Collector GUI

    In the Collector GUI, the menu for following descendants has been moved from the second Data to Collect tab to the first Collect Experiment tab. The menu now supports the all option, in addition to the on and off options. Extended hardware-counter profiling (described below) is also supported.

  9. Enhanced Hardware Counter Profiling

    The collect -h command for collecting hardware counter profiling has been enhanced to work with a larger number of processors, including x86-based processors. The enhanced hardware counter profiling is available using the collect -h command, the dbx collector hwprofile command, and in the Performance Analyzer GUI, by selecting the Collect Experiment option from the File menu. The enhancements include the following:

    • The ability to concurrently collect as many counter profiles as the processor will support
    • Extended option parameters to modify counter behavior using attributes, on processors that support hardware-counter attributes.

    The new input format is upwardly compatible with the old. The new usage instructions, obtained by running collect without any command-line arguments, has changed to reflect the counter extensions. Refer to the collect(1) man page for further details.

  10. New appendfile Option Added to er_print

    A new er_print option allows the user to append the output from er_print to the end of an existing file, rather than overwriting it. The format of the new command is as follows:

        er_print -appendfile outfile
  11. Default Behavior Changed for er_src

    In previous releases, er_src would print an error message if an object was passed to er_src without the -func, -source, or -disasm option. In this release, the default er_src behavior is as if the user had used the following:

        er_src -source all -1 object
  12. Default location of Java

    The default location where the Performance Analyzer and collect utility will look for Java is the default location where the product installer places it. The path is /usr/jdk/j2sdk1.4.2_06 on Solaris, and /usr/java/j2sdk1.4.2_06 on Linux.

  13. Extended Options for collect -j

    The collect utility will accept a path to the Java installation, in addition to accepting on and off.

  14. New collect -J Option

    The new collect -J java_args provides a means of passing flag arguments to whatever Java is being used for profiling. Specifying the flag without specifying "-j on" either explicitly, or implicitly by specifying the target as a .class or .jar file, will generate an error.

  15. Changed Sampling Behavior During Pause and Resume

    Sample data is no longer recorded when the collector is paused; samples are generated prior to a pause and following a resume.

  16. Name of Pseudo Function Changed for JVM Functions in Java Mode

    The name of the pseudo function for JVM functions in Java Mode has been changed from <JVM-Overhead> to <JVM-System>.

  17. Names Changed for Subtypes of <Unknown>

    The names of the <Unknown> subtypes of data objects has been changed to be more comprehensible.

  18. Paths of Processed .er.rc Files Now Displayed

    The Performance Analyzer, er_print, and er_src display the pathnames of the .er.rc files they process. The Analyzer displays the pathnames in the Error/Warning Logs window, which can be seen when the Experiments tab is selected. The er_print and er_src utilities print the pathnames to stderr.

  19. Environment Variable JDK_1_4_2_HOME is Obsolescent

    The environment variable JDK_1_4_2_HOME, used to define the Java path to be used for data collection is now obsolescent. The environment variable will be processed in this release, but will generate a warning that it will not be supported in future releases.

  20. Heap Profiling for Java is Obsolescent

    Heap profiling is obsolescent. Heap profiling will not be supported in JVM 1.5. Java heap profiling will be processed in this release, but will generate a warning that it will not be supported in future releases.

 

E. Software Corrections

The following bugs have been fixed.

  1. Exception thrown when viewing the analyzer online help in the Chinese locale.
  2. In the Chinese locale, a core dump occurs when opening an experiment in the analyzer.
  3. SIGSEGV error in liber_dbe.so when a Java experiment is run with -j off and filtering.
  4. Segmented reloading of libjvm causes segment overlap warnings and "unknown" warnings.
  5. Messages for descendant processes are difficult to comprehend.
  6. Performance Analyzer and er_print do not indicate when a stack unwind is truncated.
  7. The data_osingle command does not recognize structure names unless a data_objects or a data_olayout command is given first.
  8. Disassembly listings do not properly resolve call targets to their symbol names unless the original object is accessible or was archived using -A copy
  9. Experiment list does not indicate which experiments are filtered out.
  10. Support for new UltraSPARC® IV and UltraSPARC IV+ chips
  11. The er_src command coredumps on some Fortran_90 OpenMP source code.

F. Problems and Workarounds

This section discusses known software problems and possible workarounds for those problems. For updates or patches, check the updated information at http://developers.sun.com/prodtech/cc/support_index.html.

Some problems are the result of bugs in the Solaris environment and can be fixed by installing the appropriate patches. For further information, see the Required Patches section in this readme. Some bugs that appear to be in the Performance Analyzer might actually be Collector bugs. Bugs in the compilers and dbx can also affect the Performance Analyzer. Some problems that are not due to bugs are also described in this section.

Bugs in the Performance Tools

  1. Java Profiling may Crash without the Latest Java Virtual Machine.

  2. Java Synchronization- and Heap-tracing may Have Performance Problems.

  3. Java Profiling Under dbx is Not Supported.

  4. Java Profiling may Lose Data During Various Operations.

  5. Cannot Print Summary Tab or Event Tab Data.

  6. Double Counting of Metrics on Parallel Directive Lines

  7. Color-Chooser Legend-Panel Not Always Updated

  8. Libraries with Different Architectures May Not Be Properly Handled when Archived

  9. Cannot Run More than One Experiment from a Single dbx session.

  10. Stack Unwind for Optimized x86 or AMD64 Code May Fail.

 

  1. Java Profiling may Crash without the Latest Java Virtual Machine.

    Java profiling using a JVM machine earlier than 1.4.2_02 may fail due to bugs in the JVM software. It will always fail on the Intel platform with a JVM machine earlier than 1.4.2_02. A warning is written to the experiment if an earlier JVM is used. (Java programming language bugs 4757672, 4762958, 4763610, 4808151, 4812196, 4505739)

  2. Java Synchronization- and Heap-tracing May Have Performance Problems.

    Java synchronization and Heap-tracing may have performance problems, especially in processing large experiments with Heap-tracing.

  3. Java Profiling Under dbx is Not Supported.

    Java profiling using the dbx collector, or the collector Graphical Interface from the Sun Studio IDE, is not supported, because the JVM software can not support both a debugging agent and a profiling agent. (4771337)

  4. Java Profiling May Lose Data During Various Operations.

    Data collection may lose data during garbage collection, and during calls to system.* methods, during monitor-waits, or at various other times. The JVM software does not unwind the Java stack at such times. When this happens, the event is attributed to the artificial function, <no java callstack recorded>. (4824989, 4762954)

  5. Cannot Print Summary Tab or Event Tab Data.

    The Performance Analyzer cannot print the data in the Summary tab or the Event tab. To print summary data for a function or a load object, you can use the er_print command. (4286674)

  6. Double Counting of Metrics on Parallel Directive Lines

    Metrics that are reported on parallelization compiler directive lines in annotated source code are double-counted. The metrics on the source lines in the parallel do, for or section blocks of code are correct. There are also some double counting errors at the function level. (4656193)

  7. Color-Chooser Legend-Panel Not Always Updated

    The color-chooser legend-panel is not always updated when colors are changed. (4948522)

  8. Libraries with Different Architectures May Not Be Properly Handled when Archived

    Libraries with the same name but different architecture, are not copied correctly when using the collect -A copy command. (4970739)

  9. Cannot Run More than One Experiment from a Single dbx session.

    Attempting to run multiple experiments from a single dbx session will fail. (4999242)

  10. Stack Unwind for Optimized x86 or AMD64 Code May Fail.

    This problem can occur on both Solaris and Linux platforms. (5084134)

    For the Sun Studio compilers, a workaround is to compile with the the following option:

         -xregs=no%frameptr

    For GNU compilers, specify the following compiler option to get the best stack unwind results:

              -fno-omit-frame-pointer
Linux-Specific Performance Tools Bugs

  1. Profiling under dbx is not supported

  2. MP Profiling Undercounts Data from Parallel Threads

  3. Java Profiling Does Not Show Demangled Names from the JVM

  4. Sample Data for MP Programs May Be Incorrect

 

  1. Profiling under dbx is not supported

    This limitation applies to all versions of Linux.

  2. MP Profiling Undercounts Data from Parallel Threads

    The problem occurs on some Red Hat and SUSE versions of Linux. (5020387)

  3. Java Profiling Does Not Show Demangled Names from the JVM

    The problem occurs with JVM 1.4.2_02 and later 1.4.x versions of the JVM, and JVM 1.5 that are built with GNU 2.x, which is not a supported compiler. The problem is due to a bug in the demangler that will not be fixed. (no bug number)

  4. Sample Data for MP Programs May Be Incorrect

    CPU times may be inconsistent with sample times. (5025963)

 

Problems That Can Be Fixed With Solaris Environment Patches

The following bugs can be fixed by installing the appropriate patches to the Solaris environment. See the Required Patches section in this Readme for more information.

 

  1. Application Crash during Hardware Counter Profiling

    Under some circumstances HW-counter profiling interrupts triggers an OS bug on UltraSPARC-III processors that can cause the %y register to be corrupted. If the register is live at the time, the application may crash. This is fixed in Solaris 8, HW2 update, and in Solaris 9, update 4. The frequency of the problem is reduced by lower-resolution profiling, and/or the use of only one counter. (4793905)

 

Other Problems

  1. Lost Clock-Based Profiling Data for LWPs

  2. Lost Hardware Counter Profiling Interrupts

  3. Clock-Based Profiling Inaccuracies on Loaded Systems

  4. Altered Behavior With Applications That Install Signal Handlers

  5. Data Collection Problems When dbx is Attached to a Process

  6. Incorrect Values for Wait CPU Metric in Statistics Display and Samples

  7. Lost Clock Profiling Data Over a Small Time Period

  8. Data Collection Aborts With a Stack Overflow.

  9. Incomplete Experiment When Program Calls exec.

  10. False Recursion Shown With Tail Call Optimization.

  11. False Recursion Shown With Outline Function Optimization.

  12. Application deadlock with multiple libmtsk.a in multiple shared objects.

 

  1. Lost Clock-Based Profiling Data for LWPs

    Under some circumstances profiling interrupts (SIGPROF) for one or more LWPs may be lost when running under Solaris 8. The workaround is to use the alternate threads library in /usr/lib/lwp. (4298226)

  2. Lost Hardware Counter Profiling Interrupts

    When hardware counter profiling on a multithreaded application with libthread threads, the interrupt from a hardware counter overflow (SIGEMT) is occasionally lost and cannot be recovered. The bug exists under Solaris 8, and the workaround is to use the alternate threads library in /usr/lib/lwp. (4352643)

  3. Clock-Based Profiling Inaccuracies on Loaded Systems

    Profiling an application when there is a load on the system can result in significant undercount of User CPU time, up to 20%. The missing User CPU time shows up as either System CPU time or as Wait-CPU time. The bug exists for x86 targets only on both Solaris 8 and Solaris 9. (4509116)

  4. Altered Behavior With Applications That Install Signal Handlers

    Collecting performance data on an application that installs a signal handler can cause altered behavior of the collector or of the application. Where detected, the collector library will record a warning message in the experiment.

    When the collector library is preloaded, the collector's signal handler always re-installs itself as the primary handler, and it passes on signals that it does not use to any other handler. However, because it does not interrupt system calls, an application that installs a signal handler that does interrupt system calls can show changed behavior. In the case of the asynchronous I/O library, libaio.so, which uses SIGPROF for asynchronous cancel operations, asynchronous cancel requests arrive late. (4397578)

    If you attach dbx to the application without preloading the collector library, the collector installs its signal handler as the primary handler when collection is enabled. However, any signal handler installed subsequently takes precedence over the collector's signal handler. If this signal handler does not pass on SIGPROF and SIGEMT signals to the collector's signal handler, profiling data is lost.

  5. Data Collection Problems When dbx is Attached to a Process

    If you attach dbx to a running process without preloading the collector library, libcollector.so, there are a number of errors that can occur.

    • You may not be able to collect any data when synchronization wait tracing, heap tracing, or MPI tracing. Tracing data is collected by interposing on various libraries, and if libcollector.so is not preloaded, the interposition cannot be done.

    • If the program installs a signal handler after dbx is attached to the process, and the signal handler does not pass on the SIGPROF and SIGEMT signals, profiling data and sampling data is lost. (4397578)

    • If the program uses the asynchronous I/O library, libaio.so, clock-based profiling data and sampling data is lost, because libaio.so uses SIGPROF for asynchronous cancel operations.

    • If the program uses the hardware counter library, libcpc.so, hardware-counter overflow profiling experiments are corrupted because both the collector and the program are using the library. If the hardware counter library is loaded after dbx is attached to the process, the hardware-counter experiment can succeed provided references to the libcpc library functions are resolved by a general search rather than a search in libcpc.so.

    • If the program calls setitimer(2), clock-based profiling experiments can be corrupted because both the collector and the program are using the timer.

  6. Incorrect Values for Wait CPU Metric in Statistics Display and Samples

    Incorrect values for the Wait CPU metric are sometimes recorded in the sample packets and the global statistics. These values appear in the Statistics tab of the Performance Analyzer and affect the display of samples in the Timeline tab. (4615617)

  7. Lost Clock Profiling Data Over a Small Time Period

    Clock profiling data can appear to be lost over a period of several seconds when the system clock is being synchronized with an external source. During this time, the system clock is incremented until it is synchronized. Profile signals are delivered at the set interval, but the time stamp recorded in the profile packets includes any increment that is made between signal deliveries.

  8. Data Collection Aborts With a Stack Overflow.

    Sometimes the Collector can fail with a stack overflow error. This happens because the Collector uses the application's stack and the stack size for the application is too small to support use by the Collector. The workaround is to increase the stack size by at least 8 Kbytes. See the limit(1) man page for details. For parallel applications that use the multitasking library, the stack size for each thread must also be set using the STACKSIZE environment variable.

  9. Incomplete Experiment When Program Calls exec.

    When the program on which performance data is being collected successfully calls exec(2) or any of its variants, the experiment is terminated abnormally. Although the experiment can still be read by the Performance Analyzer or er_print, you should run er_archive(1) for the experiment on the computer on which the data was collected, to ensure that the load objects used by the program were archived correctly.

  10. False Recursion Shown With Tail Call Optimization.

    For some functions that make tail-call optimized calls from a shared object (PIC code) and require the determination of the global offset table address in order to reference a global variable, the optimized code is incorrectly reported as recursive, and the real caller is lost. (4656890)

  11. False Recursion Shown With Outline Function Optimization.

    For functions that are optimized by producing an outline function for seldom-executed code, false recursion may be shown due to the inability of the tools to determine the outline function's return address. (4800953)

  12. Application deadlock with multiple libmtsk.a in multiple shared objects

    Applications with multiple shared objects that have copies of libmtsk.a linked into them may deadlock under collect. The workaround is to set the environment variable LD_BIND_NOW before invoking the collect command. The Sun Studio 10 libmtsk.a is a shared object, so newly compiled and linked source codes will not have this problem. (4881093; compiler bug 4877490)

 

G. Limitations and Incompatibilities 

This section discusses limitations and incompatibilities with systems or other software.

  1. Performance Analyzer Requirements

  2. Profiling Multithreaded Applications

  3. Profiling Applications written in the Java Programming Language

  4. Hardware-Counter Overflow Profiling

  5. Library Interposition

  6. Finding Source and Object Files

  7. Experiment Incompatibility

  8. Use of setuid

  9. Hardware counters on Pentium processors

 

  1. Performance Analyzer Requirements

    The Performance Analyzer requires the Java 2 Software Development Kit, Standard Edition, in a version no earlier than 1.4.2_02. If you use an earlier version, the Performance Analyzer runs, but could fail, not function correctly or perform poorly.

  2. Profiling Multithreaded Applications

    When collecting experiments from applications that are implicitly or explicitly multithreaded (using libthread.so on Solaris 8), it is recommended that you collect with the alternate libthread library (/usr/lib/lwp/libthread.so or /usr/lib/lwp/64/libthread.so). If you use the Solaris 8 Operating Environment with the default libthread.so library, a warning will be issued to notify you of possible data distortion that may result.

  3. Profiling Applications Written in the Java Programming Language

    To collect Java-mode or machine-mode profiling data on an application written in the Java programming language you must use a version of the Java 2 Software Development Kit, Standard Edition, no earlier than 1.4.2_02. There are bugs in the JVM software that may cause program failure with any version earlier than 1.4.2_02.

    For best results for Java-mode profiling, you should use the version of the Java 2 Software Development Kit, Standard Edition, available as an install option with this Sun Studio release.

    Java profiling is not supported under dbx.

  4. Hardware-Counter Overflow Profiling

    Hardware-counter overflow profiling is not supported on UltraSPARC® processors earlier than the UltraSPARC® III series.

    Hardware-counter overflow profiling is not supported on versions of the operating system that precede the Solaris 8 release.

    The Collector cannot collect hardware-counter overflow data if cputrack is running on the system because cputrack takes control of the hardware counters.

  5. Library Interposition

    The Collector interposes on various system functions, including signal handling, fork and exec calls, the hardware counter library and some timing functions, to ensure that it can collect valid data. If a program uses any of these functions, its behavior can change. In particular, the profiling timer and the hardware counters are not available to a program when profiling is enabled, and system calls are not interrupted to deliver signals. This behavior affects the use of the asynchronous I/O library, libaio.so, which does interrupt system calls to deliver signals. These interpositions do not take place if you attach dbx to a running process without preloading the collector library, libcollector.so, and then enable data collection.

  6. Finding Source and Object Files

    The executable name that is generated when the debugger is attached to a process can be a relative path, not an absolute path, or the path, even though absolute, might not be accessible to the Performance Analyzer. Similar problems can arise with object files loaded from an archive (.a).

    The Performance Analyzer extracts the basename (the name following the last "/") from the recorded path in the executable or object file, and searches for the files as follows:

    1. It searches for a file with the basename under directories given by addpath or setpath commands, or as set from the Performance Analyzer Search Path tab in the Data Presentation Dialog, in the order given. The default setpath is:
      2. A. The experiment archive directories.
      B. The current working directory, that is, as ./<basename>.
    2. It searches for the file using the original recorded path.

    If it does not find the file, it generates an error or warning, showing the path as it originally appeared in the experiment.

    To enable the Performance Analyzer to find the source file, you can add the directory containing the file to the search path, or you can set up a symbolic link from the current directory that points to the actual location of the file, or you can copy the file into the experiment.

  7. Experiment Incompatibility

    The Performance Analyzer cannot load experiments created with versions of the Collector prior to the ForteTM Developer 7 software release.

  8. Use of setuid

    If the process calls setuid or executes setuid files, the Collector can fail to create an experiment due to permission problems.

    See the collect(1) man page for more information about restrictions on data collection.

  9. Hardware counters using Pentium processors

    Pentium 4 processors with HyperThreading Technology have only one set of hardware counters per physical processor. To use hardware counters on a system with Pentium 4 HT processors, a system administrator must first take the processors in the system off-line until each physical processor has only one hardware thread online. See the -v and -p options to psrinfo(1M) and the -f option to psradm(1M) for more information.

    When using multiple hardware counters on a Pentium 4 processor, some combinations of counters can not be bound due to resource constraints. For example, the branch_retired metric cannot be measured on registers 12 and 13 simultaneously because both counters require the Pentium 4 CRU_ESCR2 ESCR to measure this event. See the processor documentation for more details.

 

H. Documentation Errors

This section discusses documentation problems were detected in the Sun Studio 9 release and corrected in the current release.

  1. Application Interdependence When Changing Default Metrics in .er.rc Files
  2. Incomplete documentation of er_print -source function`file`
  3. Documentation of Navigation Feature Missing in Description of Analyzer Source View
  4. Performance Analyzer manual is not up-to-date
  1. Application Interdependence When Changing Default Metrics in .er.rc Files

    The analyzer(1), er_print(1), and er_src(1) man pages have been corrected to note that they all use a common .er.rc file, and thus changing and saving the default display behavior in the Analyzer, or by directly editing the .er.rc file, will affect subsequent invocations of er_print and er_src as well as the Analyzer.

  2. Incomplete documentation of er_print -source function`file`

    A note has been added to the er_print(1) man page to indicate that when the er_print option is invoked from the command line, backslashes must prepend the quotes around the filename, as follows

        er_print -source function\`file\`
  3. Documentation of Navigation Feature Missing in Description of Analyzer Source View

    A description has been added to the analyzer(1) man page to document alternate source index lines, including what they are, their format, and that they can be used for source code navigation by double-clicking on them.

  4. Performance Analyzer manual is not up-to-date

    The Performance Analyzer manual was not updated with information on the new features included in this release. Please see the man pages for information on the new Performance Analyzer features.

 

I. Required Patches

Some of the problems with the performance analysis tools originate in bugs in the Solaris operating system. To fix these bugs, you should install the relevant patches. To obtain a list of required patches, you can type the collect command at the command prompt with no arguments. The patches can be downloaded from http://sunsolve.sun.com. If you are using the Solaris 8 operating system, you should install an update that is no earlier than update 5 before installing patches.

The following problems can be encountered by the Collector and Performance Analyzer when the patches are not installed:

 

Copyright © 2004 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.