Collecting and Exploiting High-Accuracy Call Graph Profiles in Virtual Machines

Arnold, Matthew; Grove, David

doi:10.1109/cgo.2005.9

Cited by 42 publications

(49 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our approach improves DCG accuracy over the default sampling configuration in Jikes RVM, as well as over the counter-based sampling (CBS) configuration recommended by Arnold and Grove [4]. Compared to a perfect call graph, default sampling attains 52% accuracy and DCG correction algorithms boost accuracy to 71%; CBS by itself attains 76% accuracy and DCG correction boosts its accuracy to 85%, while adding 1% overhead.…”

Section: Introductionmentioning

confidence: 90%

“…Dynamic optimizers could collect a perfect DCG by profiling every call, but the overhead is too high [4]. Some optimizers profile calls fully for some period of time and then turn off profiling to reduce overhead [17,20].…”

Section: Collecting Dynamic Call Graphsmentioning

confidence: 99%

“…All DCG sampling approaches suffer from sampling error, and timer-based sampling suffers from timing bias. Arnold and Grove first measured and noted these inaccuracies [4].…”

Section: Introductionmentioning

confidence: 99%

“…Prior approaches sample to collect the DCG, trading accuracy for low overhead. Software sampling periodically examines the call stack to construct the DCG [4,12,17,20,24]. Hardware sampling lowers overhead by examining hardware performance counters instead of the call stack, but gives up portability.…”

Section: Introductionmentioning

confidence: 99%

“…Programs often decompose functionality into small methods, and virtual dispatch often obscures call targets at compile time. The dynamic call graph (DCG) records execution frequencies of call site-callee pairs, and dynamic optimizers use it to analyze and optimize whole-program behavior [2,3,4,5,11,21]. Prior approaches sample to collect the DCG, trading accuracy for low overhead.…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Correcting the Dynamic Call Graph Using Control-Flow Constraints

Lee

Resnick

Bond

et al.

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. To reason about programs, dynamic optimizers and analysis tools use sampling to collect a dynamic call graph (DCG). However, sampling has not achieved high accuracy with low runtime overhead. As object-oriented programmers compose increasingly complex programs, inaccurate call graphs will inhibit analysis and optimizations. This paper demonstrates how to use static and dynamic control flow graph (CFG) constraints to improve the accuracy of the DCG. We introduce the frequency dominator (FDOM), a novel CFG relation that extends the dominator relation to expose static relative execution frequencies of basic blocks. We combine conservation of flow and dynamic CFG basic block profiles to further improve the accuracy of the DCG. Together these approaches add minimal overhead (1%) and achieve 85% accuracy compared to a perfect call graph for SPEC JVM98 and DaCapo benchmarks. Compared to sampling alone, accuracy improves by 12 to 36%. These results demonstrate that static and dynamic control-flow information offer accurate information for efficiently improving the DCG.

show abstract

Section: Introductionmentioning

confidence: 90%

Section: Collecting Dynamic Call Graphsmentioning

confidence: 99%

“…All DCG sampling approaches suffer from sampling error, and timer-based sampling suffers from timing bias. Arnold and Grove first measured and noted these inaccuracies [4].…”

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Correcting the Dynamic Call Graph Using Control-Flow Constraints

Lee

Resnick

Bond

et al.

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

Cross‐profiling for Java processors

et al. 2009

View full text Add to dashboard Cite

Performance evaluation of embedded software is essential in an early development phase so as to ensure that the software will run on the embedded device's limited computing resources. Prevailing approaches either require the deployment of the software on the embedded target, which can be tedious and may be impossible in an early development phase, or rely on simulation, which can be very slow. In this paper, we introduce a customizable cross-profiling framework for embedded Java processors, including processors featuring a method cache. The developer profiles the embedded software in the host environment, completely decoupled from the target system, on any standard Java Virtual Machine, but the generated profiles represent the execution time metric of the target system. Our cross-profiling framework is based on bytecode instrumentation. We identify several pointcuts in the execution of bytecode that need to be instrumented in order to estimate the CPU cycle consumption on the target system. An evaluation using the JOP embedded Java processor as target confirms that our approach reconciles high profile accuracy with moderate overhead. Our cross-profiling framework also enables the rapid evaluation of the performance impact of possible optimizations, such as different caching strategies.

show abstract