Extended whole program paths
17 Sep 2005-pp 17-26
TL;DR: The design, generation and compression of the extended whole program path (eWPP) representation that not only captures the control flow history of a program execution but also its data dependence history is described, which enables the recovery of otherwise unrecoverable data dependences.
Abstract: We describe the design, generation and compression of the extended whole program path (eWPP) representation that not only captures the control flow history of a program execution but also its data dependence history. This representation is motivated by the observation that typically a significant fraction of data dependence history can be recovered from the control flow trace. To capture the remainder of the data dependence history we introduce disambiguation checks in the program whose control flow signatures capture the results of the checks. The resulting extended control flow trace enables the recovery of otherwise unrecoverable data dependences. The code for the checks is designed to minimize the increase in the program execution time and the extended control flow trace size when compared to directly collecting control flow and dependence traces. Our experiments show that compressed eWPPs are only 4% of the size of combined compressed control flow and dependence traces and their collection requires 20% more runtime overhead than overhead required for directly collecting the control flow and dependence traces.
Citations
More filters
06 Apr 2008
TL;DR: PiPA - Pipelined Profiling and Analysis is presented, which is a novel technique for parallelizing dynamic program profiling and analysis by taking advantage of multi-core systems and is able to speed up the overall profiling andAnalysis tasks significantly.
Abstract: Dynamic instrumentation systems are gaining popularity as means of constructing customized program profiling and analysis tools. However, dynamic instrumentation based analysis tools still suffer from performance problems. The overhead of such systems can be broken down into two components - the overhead of dynamic instrumentation and the time consumed in the user-defined analysis tools. While important progress has been made in reducing the performance penalty of the dynamic instrumentation itself, less attention has been paid to the user-defined component. In this paper, we present PiPA - Pipelined Profiling and Analysis, which is a novel technique for parallelizing dynamic program profiling and analysis by taking advantage of multi-core systems. We implemented a prototype of PiPA using the dynamic instrumentation system DynamoRIO. Our experiments show that PiPA is able to speed up the overall profiling and analysis tasks significantly. Compared to the more than 100x slowdown of Cachegrind and the 32x slowdown of Pin dcache, we achieved a mere 10.5x slowdown on an 8-core system.
45 citations
Cites background from "Extended whole program paths"
...[13] extended WPPs to also encode the me-...
[...]
25 Jul 2011
TL;DR: This work presents a novel scalable disk-based approach that supports efficient capture, indexing, and interactive navigation of arbitrarily large execution traces, and provides strong guarantees in terms of query processing time, ensuring an interactive debugging experience.
Abstract: Back-in-time debuggers offer an interactive exploration interface to execution traces. However, maintaining a good level of interactivity with large execution traces is challenging. Current approaches either maintain execution traces in memory, which limits scalability, or perform exhaustive on-disk indexing, which is not efficient enough.We present a novel scalable disk-based approach that supports efficient capture, indexing, and interactive navigation of arbitrarily large execution traces. In particular, our approach provides strong guarantees in terms of query processing time, ensuring an interactive debugging experience. The execution trace is divided into bounded-size execution blocks about which summary information is indexed. Blocks themselves are discarded, and retrieved as needed through partial deterministic replay. For querying, the index provides coarse answers at the level of execution blocks, which are then replayed to find the exact answer. Benchmarks on a prototype for Java show that the system is fast in practice, and outperforms existing back-in-time debuggers.
32 citations
Patent•
05 Dec 2006TL;DR: In this paper, a method and apparatus for disambiguating in a dynamic binary translator is described, based on a measure of likelihood of frequency of execution of the code segment and heuristically identifying one or more ambiguous memory dependencies.
Abstract: A method and apparatus for disambiguating in a dynamic binary translator is described. The method comprises selecting a code segment for load-store memory disambiguation based at least in part on a measure of likelihood of frequency of execution of the code segment; heuristically identifying one or more ambiguous memory dependencies in the code segment for disambiguation by runtime checks; based at least in part on inspecting instructions in the code segment, and using a pointer analysis of the code segment to identify all other ambiguous memory dependencies that can be removed by the runtime checks.
31 citations
16 Sep 2006
TL;DR: DEP (Detailed Execution Profile) captures the complete dynamic control flow, data dependency and memory reference of a whole program's execution, and can be collected with an average of 5 times slowdown while maintaining competitive compressibility.
Abstract: In many areas of computer architecture design and program development, the knowledge of dynamic program behavior can be very handy. Several challenges beset the accurate and complete collection of dynamic control flow and memory reference information. These include scalability issues, runtime-overhead, and code coverage. For example, while Tallam and Gupta's work on extending WPP (Whole Program Paths) showed good compressibility, their profile requires 500MBytes of intermediate memory space and an average of 23 times slowdown to be collected. To address these challenges, this paper presents DEP (Detailed Execution Profile). DEP captures the complete dynamic control flow, data dependency and memory reference of a whole program's execution. The profile size is significantly reduced due to the insight that most information can be recovered from a tightly coupled record of control flow and register value changes. DEP is collected in an infrastructure called Adept (A dynamic execution profiling tool), which uses the DynamoRIO binary instrumentation framework to insert profile-collecting instructions within the running application. DEP profiles user-level code execution in its entirety, including inter-procedural paths and the execution of multiple threads. The framework for collecting DEP has been tested on real, large and commercial applications. Our experiments show that DEP of Linux SPECInt 2000 benchmarks and Windows SysMark benchmarks can be collected with an average of 5 times slowdown while maintaining competitive compressibility. DEP's profile sizes are about 60% that of traditional profiles.
25 citations
Cites background or result from "Extended whole program paths"
...Extended Whole Program Paths (eWPP) [14] is a representation for recording control flow and dependence information....
[...]
...We also compare our relative slowdown with that of three important previous works: Pin [8], Valgrind [9] and eWPP [14]....
[...]
...al [14] proposed an extension to Larus’ work on WPP (Whole Program Paths) [6], called eWPP (extended WPP)....
[...]
TL;DR: The design, generation, and compression of the extended whole program path (eWPP) is described, representation that not only captures the control flow history of a program execution but also its data dependence history, which enables the recovery of otherwise irrecoverable data dependences.
Abstract: We describe the design, generation, and compression of the extended whole program path (eWPP), representation that not only captures the control flow history of a program execution but also its data dependence history. This representation is motivated by the observation that, typically, a significant fraction of data dependence history can be recovered from the control flow trace. To capture the remainder of the data dependence history, we introduce disambiguation checks in the program whose control flow signatures capture the results of the checks. The resulting extended control flow trace enables the recovery of otherwise irrecoverable data dependences. The code for the checks is designed to minimize the increase in program execution time and the extended control flow trace size when compared to directly collecting control flow and address traces. Our experiments show that compressed eWPPs are only one-quarter of the size of combined compressed control flow and address traces. However, their collection incurs a 5× increase in runtime overhead relative to the overhead required for directly collecting the control flow and address traces, respectively.
20 citations
Cites background from "Extended whole program paths"
...DOI = 10.1145/1275937.1275943 http://doi.acm.org/10.1145/1275937.1275943 A preliminary version of this paper appeared in PACT 2005 [Tallam et al. 2005]....
[...]
...A preliminary version of this paper appeared in PACT 2005 [Tallam et al. 2005]....
[...]
References
More filters
01 Jun 1990
TL;DR: This paper investigates the concept of the dynamic slice consisting of all statements that actually affect the value of a variable occurrence for a given program input, and introduces the economical concept of a Reduced Dynamic Dependence Graph, proportional in size to the number of dynamic slices arising during the program execution.
Abstract: Program slices are useful in debugging, testing, maintenance, and understanding of programs. The conventional notion of a program slice, the static slice, is the set of all statements that might affect the value of a given variable occurrence. In this paper, we investigate the concept of the dynamic slice consisting of all statements that actually affect the value of a variable occurrence for a given program input. The sensitivity of dynamic slicing to particular program inputs makes it more useful in program debugging and testing than static slicing. Several approaches for computing dynamic slices are examined. The notion of a Dynamic Dependence Graph and its use in computing dynamic slices is discussed. The Dynamic Dependence Graph may be unbounded in length; therefore, we introduce the economical concept of a Reduced Dynamic Dependence Graph, which is proportional in size to the number of dynamic slices arising during the program execution.
1,138 citations
"Extended whole program paths" refers background in this paper
...…IBM, Intel and NSF grants CCR-0324969, CCR-0220262, CCR-0208756, CCR-0105535, and EIA0080123 to the Univ. of Arizona. to perform path sensitive instruction scheduling and optimization by compiler researchers [3, 5, 7, 18] and path prediction and instruction fetching by architecture researchers [8]....
[...]
TL;DR: A dynamic program slice is an executable subset of the original program that produces the same computations on a subset of selected variables and inputs that can be handled more precisely and the size of slice can be significantly reduced, leading to a finer localization of the fault.
Abstract: A dynamic program slice is an executable subset of the original program that produces the same computations on a subset of selected variables and inputs. It differs from the static slice (Weiser, 1982, 1984) in that it is entirely defined on the basis of a computation. The two main advantages are the following: Arrays and dynamic data structures can be handled more precisely and the size of slice can be significantly reduced, leading to a finer localization of the fault. The approach is being investigated as a possible extension of the debugging capabilities of STAD, a recently developed System for Testing and Debugging (Korel and Laski, 1987; Laski, 1987).
742 citations
02 Dec 1996
TL;DR: A new algorithm for path profiling is described, which selects and places profile instrumentation to minimize run-time overhead and identifies longer paths than a previous technique, which predicted paths from edge profiles.
Abstract: A path profile determines how many times each acyclic path in a routine executes. This type of profiling subsumes the more common basic block and edge profiling, which only approximate path frequencies. Path profiles have many potential uses in program performance tuning, profile-directed compilation, and software test coverage. This paper describes a new algorithm for path profiling. This simple, fast algorithm selects and places profile instrumentation to minimize run-time overhead. Instrumented programs run with overhead comparable to the best previous profiling techniques. On the SPEC95 benchmarks, path profiling overhead averaged 31%, as compared to 16% for efficient edge profiling. Path profiling also identifies longer paths than a previous technique, which predicted paths from edge profiles (average of 88, versus 34 instructions). Moreover, profiling shows that the SPEC95 train input datasets covered most of the paths executed in the ref datasets.
676 citations
"Extended whole program paths" refers methods in this paper
...Execution traces have been collected and analyzed for wide range of applications such as developing new optimizations, developing new architectural techniques, and producing reliable software through testing and debugging....
[...]
[...]
TL;DR: This paper explains how to collect and represent Whole program paths and shows how to use WPPs to find hot subpaths, which are the heavily executed sequences of code that should be the focus of performance tuning and compiler optimization.
Abstract: Whole program paths (WPP) are a new approach to capturing and representing a program's dynamic---actually executed---control flow. Unlike other path profiling techniques, which record intraprocedural or acyclic paths, WPPs produce a single, compact description of a program's entire control flow, including loop iteration and interprocedural paths.This paper explains how to collect and represent WPPs. It also shows how to use WPPs to find hot subpaths, which are the heavily executed sequences of code that should be the focus of performance tuning and compiler optimization.
383 citations
"Extended whole program paths" refers background or methods in this paper
...Two common types of traces that are useful in above applications are control flow and dependence traces....
[...]
...In designing this extended trace we have the following goals: The additional information contained in the extended trace should be in form of control flow so that the existing compression algorithm by Larus [12] can be used to compress the extended trace....
[...]
...Essentially, since the memory dependences are at the granularity of statements, while control traces are at the granularity of basic blocks (or Ball-Larus paths), dependence traces are longer than control flow traces....
[...]
...Moreover, Sequitur based compression techniques are very effective for control flow traces [12] but significantly less so for dependence traces....
[...]
TL;DR: If debugging tools provided explicit support for many tasks manually that the tools could perform automatically, the debugging process could be automated to a significant extent.
Abstract: Programmers spend considerable time debugging code. Symbolic debuggers provide some help but the task remains complex and difficult. Other than breakpoints and tracing, these tools provide little high-level help. Programmers must perform many tasks manually that the tools could perform automatically, such as finding which statements in the program affect the value of an output variable for a given test case, and what was the value of a given variable when the control last reached a given program location. If debugging tools provided explicit support for these tasks, the debugging process could be automated to a significant extent.
In this paper we present a debugging model, based on dynamic program slicing and execution backtracking techniques, that easily lends itself to automation. This model is based on experience with using these techniques to debug software. We also present a prototype debugging tool, SPYDER, that explicitly supports the proposed model, and with which we are performing further debugging research.
338 citations
"Extended whole program paths" refers background in this paper
...…IBM, Intel and NSF grants CCR-0324969, CCR-0220262, CCR-0208756, CCR-0105535, and EIA0080123 to the Univ. of Arizona. to perform path sensitive instruction scheduling and optimization by compiler researchers [3, 5, 7, 18] and path prediction and instruction fetching by architecture researchers [8]....
[...]