Compilation and Instrumentation in DTrace
When you write traditional programs in Oracle Solaris, you use a compiler to convert the program from source code into object code that you can execute. Running the dtrace command invokes the complier for the D language. DTrace sends the compiled program to the operating system kernel for execution. In the kernel, the probes that are named in your program are enabled and the corresponding provider performs whatever instrumentation is needed to activate them.
All of the instrumentation in DTrace is completely dynamic. Probes are enabled discretely only when you are using DTrace instrumentation. No instrumented code is present for inactive probes, so the system does not experience any kind of performance degradation when you are not using DTrace. Once your experiment is complete and the dtrace command exits, all of the probes you used are automatically disabled and their instrumentation is removed, returning your system to its exact original state. No effective difference exists between a system where DTrace is not active and one where the DTrace software is not installed.
The instrumentation for each probe is performed dynamically on the live running operating system or on user processes you select. The system is not quiesced or paused in any way, and instrumentation code is added only for the probes that you enable. As a result, the probe effect of using DTrace is limited to exactly what you ask DTrace to do: no extraneous data is traced, no one big "tracing switch" is turned on in the system, and all of the DTrace instrumentation is designed to be as efficient as possible. These features enable you to use DTrace in production to solve real problems in real time.
The DTrace framework also provides support for an arbitrary number of virtual clients. You can run as many simultaneous DTrace experiments and commands as you like, limited only by the system's memory capacity, and the commands all operate independently using the same underlying instrumentation. This same capability also enables any number of distinct users on the system to take advantage of DTrace simultaneously: developers, administrators, and service personnel can all work together on distinct problems on the same system using DTrace without interfering with one another.
Unlike programs written in C and C++ and similar to programs written in the Java programming language, DTrace D programs are compiled into a safe intermediate form that is used for execution when your probes fire. This intermediate form is validated for safety when your program is first examined by the DTrace kernel software. The DTrace execution environment also handles any run-time errors that might occur during your D program's execution, including dividing by zero, dereferencing invalid memory, and so on, and reports them to you. As a result, you can never construct an unsafe program that would cause DTrace to inadvertently damage the Oracle Solaris kernel or one of the processes running on your system. These safety features allow you to use DTrace in a production environment without worrying about crashing or corrupting your system. If there is a mistake in the program, DTrace reports the error and disables the instrumentation. You can rectify the program and try again. The DTrace error reporting and debugging features are described later in this book.
The following diagram shows the different components of the DTrace architecture, including providers, probes, the DTrace kernel software, and the dtrace command.
Figure 1 DTrace Architecture and Components
