Extensive work has been done in CPU time profiling. The gprof tool [11], for example, is an sample-based profiler that records call graphs, instead of flat profiles. Recent research [7] [18] [19] has improved the performance and accuracy of time profilers based on code instrumentation. Analysis techniques have been developed such that instrumentation code may be inserted with as little run-time overhead as possible [5] [1]. Our sampling-based CPU time profiling uses stack traces to report CPU usage hot-spots, and is the most similar to the technique of call graph profiling [12]. Sansom et al [20] investigated how to properly attribute costs in profiling higher-order lazy functional programs. Appel et al [2] studied how to efficiently instrument code in the presence of code inlining and garbage collection. None of the above work addresses the issues in profiling multi-threaded programs, however.
Issues similar to profiling multi-threaded programs arise in parallel programs [3] [13], where the profiler typically executes concurrently with the program, and can selectively profile parts of the program.
Heap profiling similar to that reported in this paper has been developed for C, Lisp [22], and Modula-3 [9]. To our knowledge, our work is the first that constructs a heap profiling interface that is independent of the underlying garbage collection algorithm.
We have a general-purpose profiling architecture, but sometimes it is also useful to build custom profilers [8] that target specific compiler optimizations.
There have been numerous earlier experiments (for example, [6]) on building interactive profiling tools for Java applications. These approaches are typically based on placing custom instrumentation in the Java virtual machine implementation.