Performance analysis of idle programs

Altman, Erik R.; Arnold, Matthew; Fink, Stephen J.; Mitchell, N.

doi:10.1145/1869459.1869519

Cited by 73 publications

(35 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As a more general problem Xu et al 2010b;Xu 2011], software bloat analysis [Mitchell 2006;Mitchell and Sevitsky 2007;Xu and Rountev 2008, Xu et al 2009, 2010aMitchell et al 2009;Shankar et al 2008;Altman et al 2010;Xiao et al 2011;Yan et al 2012] attempts to find, remove, and prevent performance problems due to inefficiencies in the code execution and the use of memory. Prior work Mitchell and Sevitsky 2007] proposes metrics to provide performance assessment of use of data structures.…”

Section: Software Bloat Analysismentioning

confidence: 99%

Precise memory leak detection for java software using container profiling

Rountev

2013

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

A memory leak in a Java program occurs when object references that are no longer needed are unnecessarily maintained. Such leaks are difficult to detect because static analysis typically cannot precisely identify these redundant references, and existing dynamic leak detection tools track and report fine-grained information about individual objects, producing results that are usually hard to interpret and lack precision.In this article we introduce a novel container-based heap-tracking technique, based on the fact that many memory leaks in Java programs occur due to incorrect uses of containers, leading to containers that keep references to unused data entries. The novelty of the described work is twofold: (1) instead of tracking arbitrary objects and finding leaks by analyzing references to unused objects, the technique tracks only containers and directly identifies the source of the leak, and (2) the technique computes a confidence value for each container based on a combination of its memory consumption and its elements' staleness (time since last retrieval), while previous approaches do not consider such combined metrics. Our experimental results show that the reports generated by the proposed technique can be very precise: for two bugs reported by Sun, a known bug in SPECjbb 2000, and an example bug from IBM developerWorks, the top containers in the reports include the containers that leak memory.

show abstract

Section: Software Bloat Analysismentioning

confidence: 99%

Precise memory leak detection for java software using container profiling

Rountev

2013

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

show abstract

“…To allow the community to build upon our research and results, with the help of researchers from North Carolina State University, our approach was applied on one popular third-party application 3 . Such case reflects situations where users of our approach take the role of third-party performance analysts (other than the developers of the application), lacking deep knowledge of the code base of the application.…”

Section: B Study Results On a Third-party Applicationmentioning

confidence: 99%

“…To analyze a few sampled trace streams collected from deployment sites of modern enterprise-class multi-tier server applications, the IBM Whole-system Analysis of Idle Time (WAIT) approach [3] helps analysts diagnose idle time (indicating a lack of forward motion), which corresponds to wait bugs handled by StackMine (which also handles CPU consumption bugs). Their approach heavily relies on an extensible set of manually specified declarative rules to abstract traces to states of observed idleness.…”

Section: Related Workmentioning

confidence: 99%

Performance debugging in the large via mining millions of stack traces

Han

Dang

et al. 2012

2012 34th International Conference on Software Engineering (ICSE)

118

View full text Add to dashboard Cite

Given limited resource and time before software release, development-site testing and debugging become more and more insufficient to ensure satisfactory software performance. As a counterpart for debugging in the large pioneered by the Microsoft Windows Error Reporting (WER) system focusing on crashing/hanging bugs, performance debugging in the large has emerged thanks to available infrastructure support to collect execution traces with performance issues from a huge number of users at the deployment sites. However, performance debugging against these numerous and complex traces remains a significant challenge for performance analysts. In this paper, to enable performance debugging in the large in practice, we propose a novel approach, called StackMine, that mines callstack traces to help performance analysts effectively discover highly impactful performance bugs (e.g., bugs impacting many users with long response delay). As a successful technology-transfer effort, since December 2010, StackMine has been applied in performance-debugging activities at a Microsoft team for performance analysis, especially for a large number of execution traces. Based on real-adoption experiences of StackMine in practice, we conducted an evaluation of StackMine on performance debugging in the large for Microsoft Windows 7. We also conducted another evaluation on a third-party application. The results highlight substantial benefits offered by StackMine in performance debugging in the large for large-scale software systems.

show abstract

“…Application work is the sum of all active execution times of all application threads (excluding JVM threads), i.e., the total area of all application thread boxes. 2 Likewise, we define application time as the sum of all execution time shares of all application threads, i.e., the total height of the application thread boxes. Along the same lines, we define garbage col- 2 We classify the MainThread as part of the application.…”

Section: Jikes Rvm and Benchmark Analysismentioning

confidence: 99%

“…The work most related to ours is IBM's WAIT tool [2], which also analyzes the performance and scalability of multi-threaded Java programs. However, bottle graphs reveal much more information at a much lower overhead.…”

Section: Introductionmentioning

confidence: 99%

Bottle graphs

Bois

Sartor

Eyerman

et al. 2013

Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Programming Systems Languages &Amp; Application

View full text Add to dashboard Cite

Understanding and analyzing multi-threaded program performance and scalability is far from trivial, which severely complicates parallel software development and optimization. In this paper, we present bottle graphs, a powerful analysis tool that visualizes multi-threaded program performance, in regards to both per-thread parallelism and execution time. Each thread is represented as a box, with its height equal to the share of that thread in the total program execution time, its width equal to its parallelism, and its area equal to its total running time. The boxes of all threads are stacked upon each other, leading to a stack with height equal to the total program execution time. Bottle graphs show exactly how scalable each thread is, and thus guide optimization towards those threads that have a smaller parallel component (narrower), and a larger share of the total execution time (taller), i.e. to the 'neck' of the bottle.Using light-weight OS modules, we calculate bottle graphs for unmodified multi-threaded programs running on real processors with an average overhead of 0.68%. To demonstrate their utility, we do an extensive analysis of 12 Java benchmarks running on top of the Jikes JVM, which introduces many JVM service threads. We not only reveal and explain scalability limitations of several well-known Java benchmarks; we also analyze the reasons why the garbage collector itself does not scale, and in fact performs optimally with two collector threads for all benchmarks, regardless of the number of application threads. Finally, we compare the scalability of Jikes versus the OpenJDK JVM. We demonstrate how useful and intuitive bottle graphs are as a tool to analyze scalability and help optimize multi-threaded applications.

show abstract

Performance analysis of idle programs

Cited by 73 publications

References 14 publications

Precise memory leak detection for java software using container profiling

Precise memory leak detection for java software using container profiling

Performance debugging in the large via mining millions of stack traces

Bottle graphs

Contact Info

Product

Resources

About