The SPARC architecture provides a fixed set of register windows that are allocated for each function call, providing very fast access to function arguments and local variables. Allocating and releasing a new window typically takes a single instruction cycle at function entry and exit. When the set of register windows is exhausted, however, the hardware issues a trap to the operating system to save and later restore the contents of a window to memory.
Register-window trap processing by the operating system is relatively expensive, taking several hundred instruction cycles in a simple case. For programs with deeply nested function calls such as highly recursive programs, the accumulated cost of handling register-window traps can dominate the actual computation of the function itself.
By default, Quantify does not time register-window traps. As a consequence, the predicted times in the program summary report are optimistic, since they do not account for this hidden cost. Although this time is excluded, if the register-window trap times are substantial, Quantify reports this time in a separate category in the program summary. Quantify provides options and an API function that allow you to time register-window traps. For more information, read Timing register-window traps.
When you request that Quantify time register window traps, Quantify tracks each register window save-and-restore request at run time. By simulating the register-window mechanism, Quantify records the time spent by the operating system in preserving and restoring register windows required by your program. Quantify allocates the time for handling the overflow and underflow to the function that caused it.
Quantify provides this level of detail so that you can design ways to minimize the performance impact of register-window traps on your programs.