JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.3: Performance Analyzer     Oracle Solaris Studio 12.3 Information Library
search filter icon
search icon

Document Information

Preface

1.  Overview of the Performance Analyzer

2.  Performance Data

3.  Collecting Performance Data

4.  The Performance Analyzer Tool

5.  The er_print Command Line Performance Analysis Tool

er_print Syntax

Metric Lists

Commands That Control the Function List

functions

metrics metric_spec

sort metric_spec

fsummary

fsingle function_name [N]

Commands That Control the Callers-Callees List

callers-callees

csingle function_name [N]

cprepend function-name [N | ADDR]

cappend function-name [N | ADDR]

crmfirst

crmlast

Commands That Control the Call Tree List

calltree

Commands That Control the Leak and Allocation Lists

leaks

allocs

Commands That Control the Source and Disassembly Listings

pcs

psummary

lines

lsummary

source|src { filename | function_name } [ N]

disasm|dis { filename | function_name } [ N]

scc com_spec

sthresh value

dcc com_spec

dthresh value

cc com_spec

Commands That Control Searching For Source Files

setpath path_list

addpath path_list

pathmap old-prefix new-prefix

Commands That Control Hardware Counter Dataspace and Memory Object Lists

data_objects

data_single name [N]

data_layout

memobj mobj_type

mobj_list

mobj_define mobj_type index_exp

Commands That Control Index Object Lists

indxobj indxobj_type

indxobj_list

indxobj_define indxobj_type index_exp

Commands for the OpenMP Index Objects

OMP_preg

OMP_task

Commands That Support the Thread Analyzer

races

rdetail race_id

deadlocks

ddetail deadlock_id

Commands That List Experiments, Samples, Threads, and LWPs

experiment_list

sample_list

lwp_list

thread_list

cpu_list

Commands That Control Filtering of Experiment Data

Specifying a Filter Expression

filters filter_exp

Listing Keywords for a Filter Expression

describe

Selecting Samples, Threads, LWPs, and CPUs for Filtering

Selection Lists

Selection Commands

sample_select sample_spec

lwp_select lwp_spec

thread_select thread_spec

cpu_select cpu_spec

Commands That Control Load Object Expansion and Collapse

object_list

object_show object1,object2,...

object_hide object1,object2,...

object_api object1,object2,...

objects_default

object_select object1,object2,...

Commands That List Metrics

metric_list

cmetric_list

data_metric_list

indx_metric_list

Commands That Control Output

outfile {filename|-|--}

appendfile filename

limit n

name { long | short } [ :{ shared_object_name | no_shared_object_name } ]

viewmode { user| expert | machine }

compare { on | off }

Commands That Print Other Information

header exp_id

ifreq

objects

overview exp_id

statistics exp_id

Commands That Set Defaults

dmetrics metric_spec

dsort metric_spec

en_desc { on | off | =regexp}

Commands That Set Defaults Only For the Performance Analyzer

tabs tab_spec

rtabs tab_spec

tlmode tl_mode

tldata tl_data

Miscellaneous Commands

procstats

script file

version

quit

help

Expression Grammar

Example Filter Expressions

er_print command Examples

6.  Understanding the Performance Analyzer and Its Data

7.  Understanding Annotated Source and Disassembly Data

8.  Manipulating Experiments

9.  Kernel Profiling

Index

Expression Grammar

A common grammar is used for an expression defining a filter and an expression used to compute a memory object index.

The grammar specifies an expression as a combination of operators and operands or keywords. For filters, if the expression evaluates to true, the packet is included; if the expression evaluates to false, the packet is excluded. For memory objects or index objects, the expression is evaluated to an index that defines the particular memory object or index object referenced in the packet.

Operands in an expression can be labels, constants, or fields within a data record, as listed with the describe command. The operands include THRID, LWPID, CPUID , USTACK, XSTACK, MSTACK, LEAF, VIRTPC, PHYSPC, VADDR, PADDR, DOBJ, TSTAMP, SAMPLE, EXPID, PID, or the name of a memory object. Operand names are case-insensitive.

USTACK, XSTACK, and MSTACK represent the function call stacks in user view, expert view, and machine view, respectively.

VIRTPC, PHYSPC, VADDR, and PADDR are non-zero only when “+” is specified for Hardware-counter-profiling or clock-profiling. Furthermore, VADDR is less than 256 when the real virtual address could not be determined. PADDR is zero if VADDR could not be determined, or if the virtual address could not be mapped to a physical address. Likewise, VIRTPC is zero if backtracking failed, or was not requested, and PHYSPC is zero if either VIRTPC is zero, or the VIRTPC could not be mapped to a physical address.

Operators include the usual logical operators and arithmetic (including shift) operators, in C notation, with C precedence rules, and an operator for determining whether an element is in a set (IN) or whether any or all of a set of elements is contained in a set (SOME IN or IN, respectively). An additional operator ORDERED IN is for determining if all elements from the left operand appear in the same sequence in the right operand. Note that the IN operator requires all elements from the left operand to appear in the right operand but does not enforce the order. If-then-else constructs are specified as in C, with the ? and : operators. Use parentheses to ensure proper parsing of all expressions. On the er_print command lines, the expression cannot be split across lines. In scripts or on the command line, the expression must be inside double quotes if it contains blanks.

Filter expressions evaluate to a boolean value, true if the packet should be included, and false if it should not be included. Thread, CPU, experiment-id, process-pid, and sample filtering are based on a relational expression between the appropriate keyword and an integer, or using the IN operator and a comma-separated list of integers.

Time-filtering is used by specifying one or more relational expressions between TSTAMP and a time, given in integer nanoseconds from the start of the experiment whose packets are being processed. Times for samples can be obtained using the overview command. Times in the overview command are given in seconds, and must be converted to nanoseconds for time-filtering. Times can also be obtained from the Timeline display in the Analyzer.

Function filtering can be based either on the leaf function, or on any function in the stack. Filtering by leaf function is specified by a relational expression between the LEAF keyword and an integer function id, or using the IN operator and the construct FNAME("regexp"), where regexp is a regular expression as specified on the regexp(5) man page. The entire name of the function, as given by the current setting of name, must match.

Filtering based on any function in the call stack is specified by determining if any function in the construct FNAME("regexp") is in the array of functions represented by the keyword USTACK using the expression (FNAME("myfunc") SOME IN USTACK). FNAME can also be used to filter the machine view of the stack (MSTACK) and the expert view (XSTACK) in the same way.

Data object filtering is analogous to stack function filtering, using the DOBJ keyword and the construct DNAME("regexp") enclosed in parentheses.

Memory object filtering is specified using the name of the memory object, as shown in the mobj_list command, and the integer index of the object, or the indices of a set of objects. (The <Unknown> memory object has index -1.)

Index object filtering is specified using the name of the index object, as shown in the indxobj_list command, and the integer index of the object, or the indices of a set of objects. (The <Unknown> index object has index -1.)

Data object filtering and memory object filtering are meaningful only for hardware counter packets with dataspace data; all other packets are excluded under such filtering.

Direct filtering of virtual addresses or physical addresses is specified with a relational expression between VADDR or PADDR, and the address.

Memory object definitions (see mobj_define mobj_type index_exp) use an expression that evaluates to an integer index, using either the VADDR keyword or PADDR keyword. The definitions are applicable only to hardware counter packets for memory counters and dataspace data. The expression should return an integer, or -1 for the <Unknown> memory object.

Index object definitions (see indxobj_define indxobj_type index_exp) use an expression that evaluates to an integer index. The expression should return an integer, or -1 for the <Unknown> index object.

Example Filter Expressions

This section shows examples of filter expressions that can be used with the er_print -filters command, and in the Custom tab of the Performance Analyzer's Manage Filter dialog box.

With the er_print -filters command, the filter expression is enclosed in single quotes, similar to the following:

er_print -filters 'FNAME("myfunc") SOME IN USTACK' -functions test.1.er

Example 5-1 Filter functions by name and stack

To filter functions named myfunc from the user function stack:

FNAME("myfunc") SOME IN USTACK

Example 5-2 Filter events by thread and CPU

To see events from thread 1 when it was running on CPU 2 only, use:

THRID == 1 && CPUID == 2

Example 5-3 Filter events by index object

If an index object, THRCPU, is defined as "CPUID<<16|THRID", the following filter is equivalent to the one above to see events from thread 1 when it was running on CPU 2:

THRCPU == 0x10002

Example 5-4 Filter events occurring in specified time period

To filter events from experiment 2 that occurred during the period between second 5 and second 9:

EXPID==2 && TSTAMP >= 5000000000 && TSTAMP < 9000000000

Example 5-5 Filter events from a particular Java class

To filter events that have any method from a particular Java class in the stack (in user view mode):

FNAME("myClass.*") SOME IN USTACK

Example 5-6 Filter events by internal function ID and call sequence

If function IDs are known (as shown in the Analyzer), to filter events that contain a particular call sequence in the machine call stack:

(314,272) ORDERED IN MSTACK

Example 5-7 Filter events by state or duration

If the describe command lists the following properties for a clock profiling experiment:

MSTATE    UINT32  Thread state
NTICK     UINT32  Duration

you can select events that are in a particular state using the following filter:

MSTATE == 1

Alternatively, you can use the following filter to select events that are in a particular state and whose duration is longer than 1 clock tick:

MSTATE == 1 && NTICK > 1