This section describes the limitations on data collection that are imposed by the hardware, the operating system, the way you run your program, or by the Collector itself.
There are no limitations on simultaneous collection of different data types. You can collect any data type with any other data type, with the exception of count data.
By default, the Collector collects stacks that are, at most, up to 256 frames deep. If the stack is deeper, you might see the <Truncated-stack> function in er_print and Performance Analyzer. See <Truncated-stack> Function for more information. To support deeper stacks, set the SP_COLLECTOR_STACKBUFSZ environment variable to a larger number.
The minimum value of the profiling interval and the resolution of the clock used for profiling depend on the particular operating environment. The maximum value is set to 1 second. The value of the profiling interval is rounded down to the nearest multiple of the clock resolution. To display the minimum and maximum value and the clock resolution, type the collect command with no additional arguments.
You cannot do clock profiling on a program that uses the profiling timer. The Collector intercepts calls to setitimer(3) that set the profiling clock parameters and prevents other programs from using them.
On Linux platforms, the clock data can only be shown as Total CPU time. Linux CPU time is the sum of user CPU time and system CPU time.
On Linux systems, clock-profiling of multithreaded applications might report inaccurate data for threads. The profile signal is not always delivered by the kernel to each thread at the specified interval; sometimes the signal is delivered to the wrong thread. If available, hardware counter profiling using the cycle counter will usually give more accurate data for threads.
Clock profiling records data when a SIGPROF signal is delivered to the target. It causes dilation to process that signal, and unwind the call stack. The deeper the call stack and the more frequent the signals, the greater the dilation. To a limited extent, clock profiling shows some distortion, deriving from greater dilation for those parts of the program executing with the deepest stacks.
Where possible, a default value is set not to an exact number of milliseconds, but to slightly more or less than an exact number (for example, 10.007 ms or 0.997 ms) to avoid correlations with the system clock, which can also distort the data. Set custom values the same way on Oracle Solaris platforms (not possible on Linux platforms).
You cannot collect any kind of tracing data from a program that is already running unless the Collector library, libcollector.so, had been preloaded. See Collecting Tracing Data From a Running Program for more information.
Tracing data dilates the run in proportion to the number of events that are traced. If done with clock profiling, the clock data is distorted by the dilation induced by tracing events.
Hardware counter profiling has several limitations:
You can only collect hardware counter data on processors that have hardware counters and that support hardware counter profiling. On other systems, hardware counter profiling is disabled. Oracle Solaris and Oracle Linux with Unbreakable Enterprise Kernel or Red Hat-compatible kernel 6.0 and newer do support hardware counters.
You cannot collect hardware counter data on a system running Oracle Solaris while the cpustat(1) command is running because cpustat takes control of the counters and does not let a user process use the counters. If cpustat is started during data collection, the hardware counter profiling is terminated and an error is recorded in the experiment. The same is true if root starts an er_kernel experiment using hardware counters.
You cannot use the hardware counters in your own code if you are doing hardware counter profiling. The Collector interposes on the libcpc library functions and returns with a return value of -1 if the call did not come from the Collector. Your program should be coded so as to work correctly if it fails to get access to the hardware counters. If not coded to handle this, the program will fail under hardware counter profiling, or if the superuser invokes system-wide tools that also use the counters, or if the counters are not supported on that system.
If you try to collect hardware counter data on a running program that is using the hardware counter library by attaching dbx to the process, the experiment might be corrupted or the program might fail.
Hardware counter profiling records data when a SIGEMT signal (on Oracle Solaris platforms) or a SIGIO signal (on Linux platforms) is delivered to the target. It causes dilation to process that signal and unwind the call stack. Unlike clock profiling, for some hardware counters, different parts of the program might generate events more rapidly than other parts and show dilation in that part of the code. Any part of the program that generates such events very rapidly might be significantly distorted. Similarly, some events might be generated in one thread disproportionately to the other threads.
You can collect data on descendant processes subject to some limitations.
If you want to collect data for all descendant processes that are followed by the Collector, you must use the collect command with one of the following options:
-F on option enables you to collect data automatically for calls to fork and its variants and exec and its variants, and all other descendant processes, including those due to calls to system, popen, posix_spawn(3p), posix_spawnp(3p), and sh
-F all is the same as -F on.
–F '=regexp' option enables data to be collected on all descendant processes whose name matches the specified regular expression.
See Experiment Control Options for more information about the –F option.
Collecting OpenMP data during the execution of the program can be very expensive. You can suppress that cost by setting the SP_COLLECTOR_NO_OMP environment variable. If you do so, the program will have substantially less dilation, but you will not see the data from slave threads propagate up to the caller, and eventually to main(), as it normally will if that variable is not set.
OpenMP profiling functionality is available only for applications compiled with the Oracle Developer Studio compilers because it depends on the Oracle Developer Studio compiler runtime. For applications compiled with GNU compilers, only machine-level call stacks are displayed.
You can collect data on Java programs subject to the following limitations:
You should use a version of the Java 2 Software Development Kit (JDK) no earlier than JDK 7, Update 25 (JDK 1.7.0_25). The Collector first looks for the JDK in the path set in either the JDK_HOME environment variable or the JAVA_PATH environment variable. If neither of these variables is set, it looks for a JDK in your PATH. If there is no JDK in your PATH, it looks for the java executable in /usr/java/bin/java.
The Collector verifies that the version of the java executable it finds is an ELF executable. If it is not, an error message is printed indicating which environment variable or path was used and the full path name that was tried.
You must use the collect command to collect data. You cannot use the dbx collector subcommands.
Some applications are not pure Java, but are C or C++ applications that invoke dlopen() to load libjvm.so, and then start the JVM software by calling into it. To profile such applications, set the SP_COLLECTOR_USE_JAVA_OPTIONS environment variable. Do not set the LD_LIBRARY_PATH environment variable for this scenario.
Java profiling uses the Java Virtual Machine Tools Interface (JVMTI), which can cause some distortion and dilation of the run.
For clock profiling and hardware counter profiling, the data collection process makes various calls into the JVM software and handles profiling events in signal handlers. The overhead of these routines and the cost of writing the experiments to disk will dilate the runtime of the Java program. Such dilation is typically less than 10%.