| Skip Navigation Links | |
| Exit Print View | |
|
What's New in the Oracle Solaris Studio 12.3 Release Oracle Solaris Studio 12.3 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
What's New in the Oracle Solaris Studio 12.3 Release Oracle Solaris Studio 12.3 Information Library |
1. Introducing the Oracle Solaris Studio 12.3 Release
7. The Oracle Solaris Studio IDE
9. Known Problems, Limitations, and Workarounds in This Release
This section describes the new and changed features in this release of the Oracle Solaris Studio Performance Analyzer and related tools. For details, see the Oracle Solaris Studio 12.3: Performance Analyzer manual and the Help in the Performance Analyzer.
The Performance Analyzer tool features the following enhancements.
Performance for processing large experiments, especially for Java experiments, is significantly improved.
Many improvements were made for data filtering, described in Filtering Enhancements.
Most data tabs now include context menus, which you open by right-clicking in the tabs. These context menus can be used to discover advanced tab-specific features, such as filtering.
Experiment Comparison mode now supports comparing experiments on different executables and load objects. Source and disassembly for comparison is now shown in split panes for the two versions. Experiment Comparison mode can be enabled from context menus in the Functions and Source tabs.
Quick navigation improvements in tabs enable you to do the following:
Double click on a function in the Functions tab to open the Source tab for that function.
Double click in a line in the Lines tab to open the Source tab at or near that line.
Double click on a line in the Source tab to open the Disassembly tab at or near the first instruction from that line.
Double click on a PC in the PCs tab to open the Disassembly tab at or near that address.
The method used to search for source files referenced in experiments has changed. The pathmap is tried first, and then the search path combined with the pathmap is tried, then the original full path.
Many improvements were made to the timeline, described in Timeline Enhancements.
The Call Tree tab converts HW cycles to User CPU Time, and you can set the metric displayed in the Call Tree from the context menu.
The Threads tab has an new display mode called Chart. When Chart is enabled for an experiment containing clock profiling data, the default Load Imbalance chart shows the total amount of CPU Time attributed to each thread.
The Timeline tab of the Performance Analyzer features the following enhancements:
You can right-click on the Timeline to open a context menu to filter data, select events, zoom in and out, revert to the previous view, or change timeline properties.
An event frequency chart, a line chart that displays frequency of events as a function of time. The chart is not displayed by default, and must be selected in the Set Data Preferences dialog box.
An event state chart, a bar chart that shows the distribution of application time spent in various states as a function of time. For clock profiling data recorded on Oracle Solaris, the event state chart shows Oracle Solaris microstates. The chart is not displayed by default, and must be selected in the Set Data Preferences dialog box.
Double-clicking in the Timeline now zooms in rather than opening the function color chooser dialog.
A new Timeline Details tab replaces the Event tab. The new tab provides the event information as before, and also includes buttons for navigating the timeline, zooming, and changing function colors.
Timeline now uses the font you specify when starting the Performance Analyzer.
The timeline can be set to display aggregated events from each experiment. This is not a default setting and must be set be selecting Group Data by: Experiment in the Timeline tab of the Set Data Preferences dialog box.
Data filtering in the Performance Analyzer has been simplified and enhanced:
Most data tabs now include context filters, which you select by right-clicking in the tabs. The names of new and existing context filters are also easier to understand.
Context filters now filter data immediately and no longer require you to apply them in a separate dialog box. Selection of a context menu filter affects the data used by all tabs. Each filter selected is AND'ed with any existing filters, enabling you to progressively filter the data.
The Filter Data dialog box was simplified and renamed to Manage Data Filters. However, filtering from the context menus in data tabs is the recommended way to filter data.
The Custom tab of the Manage Data Filters dialog box can be used to view the current state of filters that were applied from context menus. The Custom tab allows user editing of the current filter expression. It also supports undo, redo, and Show Keywords, a dialog box that describes symbols that may appear in filtering expressions that are generated by the context menu filters.
You can filter experiments using labels that you add with the new er_label command.
The online help includes expanded information about filtering.
See Filtering Data in Oracle Solaris Studio 12.3: Performance Analyzer for more information.
The er_label command enables you to define part of an experiment and assign a name or label to it. The label captures the profiling events that occur during one or more periods of time in the experiment that you define with start time and stop time markers.
You can assign labels to experiments by running the er_label command at the command line or by executing it in scripts. Once you have added labels to an experiment, you can use the labels for filtering. For example, you might filter the experiment to include or exclude the profiling events in the time periods defined by the label.
One use of er_label is to support profiling a server program that is being driven by a client as an independent process or processes. In this usage model, you start the server with the collect command to start creating an experiment on the server. Once the server is started and ready to accept requests from a client, you can run a client script that makes requests to drive the server and runs er_label to label the portions of the experiment where the client requests occur.
See Labeling Experiments in Oracle Solaris Studio 12.3: Performance Analyzer for more information.
The experiment format has changed and the version number is now 12.3, which matches the Oracle Solaris Studio version number.
The tools in Oracle Solaris Studio 12.3 can open experiments with the following version numbers:
version 10.1, experiments created with Oracle Solaris Studio 12.2 or Sun Studio 12 update 1.
version 10.2, experiments created with an early release of Oracle Solaris Studio 12.3 such as the Beta release.
version 12.3, experiments created with the released version of Oracle Solaris Studio 12.3.
If you try to open experiments created from a prior release, you get an error saying that the experiment must be read with an earlier version of the tools.
Data collection changes affect the collect command, dbx collector command, and er_kernel command.
The collect utility is changed in this release as follows:
collect does not verify that the target program is an ELF executable, which enables you to profile scripts without setting an environment variable. If the target is an ELF executable, collect checks it for compatibility with the machine on which it is running.
Hardware counter support for SPARC T4, and Intel's Westmere and Sandy Bridge chips has been added for Oracle Solaris. Westmere support has been added for Linux, but Sandy Bridge support for Linux is not yet implemented.
Hardware counter profiling now enables you to perform memoryspace profiling of any binary by prepending ”+” to any precise hardware counter. Currently only SPARC T4 and T3 processors support precise hardware counters.
To determine which hardware counters are precise, look for the keyword precise in the output of the collect -h command. To analyze memory access patterns in an experiment which includes memoryspace profiling data, select Memory Objects tabs such as Vaddress or Vline_64b in the Tabs tab of the Set Data Presentation dialog box. You can then use the context filters from the selected Memory Object tab to filter by data addresses.
Hardware counter support on versions of Linux running the Linux kernel with a version greater than 2.6.32 is implemented with the PerfEvents framework, and does not require a kernel patch; for earlier systems, the perfctr patch is still required.
Running collect without arguments now displays a usage message only. To display information about available hardware counters, you must run collect —h with no additional arguments.
High-resolution clock profiling, which is performed using collect -p high, is now available on Linux systems that support it, including Oracle Linux 6.
The dbx collector is changed in this release as follows:
Hardware counter support for SPARC T4, Westmere and Sandy Bridge chips has been added for Oracle Solaris. Westmere support has been added for Linux, but Sandy Bridge support for Linux is not yet implemented.
Hardware counter support on versions of Linux running the Linux kernel with a version greater than 2.6.32 is implemented with the PerfEvents framework, and does not require a kernel patch; for earlier systems, the perfctr patch is still required.
The er_kernel utility for profiling an Oracle Solaris kernel is changed as follows:
er_kernel now enables you to perform profiling of the kernel and applications. You can use the -F option to control whether or not application processes should be followed and have their data recorded as sub-experiments to the kernel experiment.
er_kernel no longer supports the -T option for profiling a specific process. You can use the -F option with a regular expression instead.
The er_kernel utility can collect hardware counter overflow profiles for the kernel using the DTrace cpc provider, which is available only on systems running Oracle Solaris 11. You can perform hardware counter overflow profiling of the kernel with the -h option for the er_kernel command as you do with the collect command. However, dataspace profiling is not supported so dataspace requests are ignored by er_kernel.
Running er_kernel without arguments now displays a usage message only. To display information about available hardware counters, you must run er_kernel —h with no additional arguments.
If the hardware counter overflow mechanism on the chip allows the kernel to tell which counter overflowed, you can profile as many counters as the chip provides; otherwise, you can only specify one counter. The er_kernel —h output specifies whether you can use more than one counter by displaying a message such as "specify HW counter profiling for up to 4 HW counters."
er_kernel does not verify that the target load is an ELF executable, which enables you to profile any command or script.
The er_print command is changed in this release as follows:
Performance for processing large experiments, especially for Java experiments, is significantly improved.
The method used to search for source files referenced in experiments has changed. The pathmap is tried first, and then the search path combined with the pathmap is tried, and then the original full path is tried.
The tlmode subcommand can be used to set the default for the timeline to display aggregated events from each experiment.
The following features were added or changed in Oracle Solaris Studio 12.3 Thread Analyzer.
The Thread Analyzer now informs you if your application is not instrumented for race detection profiling
The Thread Analyzer now opens the first call stack in the Races tab automatically.
|