A program profile attributes run-time costs to portions of a program's execution. Most profiling systems suffer from two major deficiencies: first, they only apportion simple metrics, such as execution frequency or elapsed time to static, syntactic units, such as procedures or statements; second, they aggressively reduce the volume of information collected and reported, although aggregation can hide striking differences in program behavior.This paper addresses both concerns by exploiting the hardware counters available in most modern processors and by incorporating two concepts from data flow analysis--flow and context sensitivity--to report more context for measurements. This paper extends our previous work on efficient path profiling to flow sensitive profiling, which associates hardware performance metrics with a path through a procedure. In addition, it describes a data structure, the calling context tree, that efficiently captures calling contexts for procedure-level measurements.Our measurements show that the SPEC95 benchmarks execute a small number (3--28) of hot paths that account for 9--98% of their L1 data cache misses. Moreover, these hot paths are concentrated in a few routines, which have complex dynamic behavior.

Exploiting hardware performance counters with flow and context sensitive profiling

Some algorithms make critical internal use of updatable state, even though their external specification is purely functional. Based on earlier work on monads, we present a way of securely encapsulating stateful computations that manipulate multiple, named, mutable objects, in the context of a non-strict, purely-functional language.The security of the encapsulation is assured by the type system, using parametricity. Intriguingly, this parametricity requires the provision of a (single) constant with a rank-2 polymorphic type.

/pdf/lazy-functional-state-threads-3uk0z14um7.pdf

Lazy functional state threads

We have developed a technology, fine-grained dynamic instrumentation of commodity kernels, which can splice (insert) dynamically generated code before almost any machine code instruction of a completely unmodified running commodity operating system kernel. This technology is well-suited to performance profiling, debugging, code coverage, security auditing, runtime code optimizations, and kernel extensions. We have designed and implemented a tool called Kernlnst that performs dynamic instrumentation on a stock production Solaris kernel running on an UltraSPARC, On top of KernInst, we have implemented a kernel performance profiling tool, and used it to understand kernel and application performance under a Web proxy server workload. We used this information to make two changes (one to the kernel, one to the proxy) that cumulatively reduce the percentage of elapsed time that the proxy spends opening disk cache files from 40% to 7%.

/pdf/fine-grained-dynamic-instrumentation-of-commodity-operating-jtlofndm0o.pdf

Fine-grained dynamic instrumentation of commodity operating system kernels

Some algorithms make critical internal use of updatable state, even though their external specification is purely functional. Based on earlier work on monads, we present a way of securely encapsulating stateful computations that manipulate multiple, named, mutable objects, in the context of a non-strict, purely-functional language. The security of the encapsulation is assured by the type system, using parametricity. The same framework is also used to handle input/output operations (state changes on the external world) and calls to C.

State in Haskell

This paper describes a portable and efficient sampling-based online measurement system for production-level Java virtual machines. This system is designed to provide continuous real time system performance measurements to a dynamic compiler, which can use these measurements to target frequently executed and time-consuming code for optimization and to make more informed optimization decisions. Because the system has very low overhead, it can be run continuously, providing a feedback mechanism to the dynamic compiler. This system utilizes a novel data structure, the partial calling context tree (PCCT), which allows the efficient encoding of approximate context-sensitive profile information. The PCCT is organized such that both incremental updates and extracting the important information are efficient operations. This online measurement system has been implemented in a cross-platform industry-leading Java Just-In-Time compiler. We present detailed performance results on a variety of platforms that show that the system is not only efficient enough to be used continuously in a production environment (2-4% slowdown for most applications) but is also surprisingly accurate in the data that it collects (typically ≥90% accurate).

/pdf/a-portable-sampling-based-profiler-for-java-virtual-machines-4l38op0vp7.pdf

A portable sampling-based profiler for Java virtual machines

Run-time program profiling is a valuable tool in understanding software efficiency. Techniques for obtaining profiles make assumptions that may result in misleading data. In the paper we illustrate flaws in two profiling systems: the Unix ‘Gprof’ family (including the packages ‘monitor’, ‘prof’ and ‘profil’), and the TI Explorer metering package for Lisp.

Inaccuracies in program profilers

Side-effects are forbidden in applicative languages like Prolog [3], FP [2], pure Lisp [9], and SISAL [8]. Algorithms can often be reformulated applicatively with no loss of efficiency. It is not known whether this is always the case. Here are seven problems which have been resistant to efficient reformulation. The reader is invited to produce an efficient applicative program or lower-bound argument for any of these.

Are applicative languages inefficient

In his influential letter "Go to statement considered harmful" [2], Edsger Dijkstra asserts that goto's make a program difficult to understand. He argues that arbitrary changes of the program control point are difficult to follow in conjunction with dynamic changes to the state of the program data. The abstract control structures of high level languages manage to limit one or the other or both. For procedure calls the control point temporarily transfers, and changes to the data state are limited to a returned result and, in general, few side effects. For conditional or iteration structures the control point locally changes according to a set pattern. True or not, Dijkstra's assertion has had a fundamental influence on software engineering and programming language design. Using the same reasoning, goto statements with variable destinations present a bigger problem. Not only can the control point move to a number of different, textually distant locations, but the choice of destination is determined by the data state. It is not enough that the programmer find where the destination lies, however far buried into the program text.; the choice of destinations must be inferred from the dynamic data state.

Carl G. Ponder

Papers

Inaccuracies in program profilers

Are applicative languages inefficient

Polymorphism considered harmful

Polymorphism considered harmful

Parallel multiplication and powering of polynomials