Understanding and detecting real-world performance bugs

Jin, Guoliang; Song, Linhai; Shi, Xiaoming; Scherpelz, Joel; Lu, Shan

doi:10.1145/2254064.2254075

Cited by 217 publications

(123 citation statements)

References 56 publications

Supporting

Mentioning

106

Contrasting

Unclassified

Order By: Relevance

“…Rather than having a full-blown monitoring, only explicit signals can be monitored. Beyond these strategies, limplock detection can leverage a rich body of literature in peer comparison [38], sampling [35], and root-cause analysis [15,33,44].…”

Section: Discussionmentioning

confidence: 99%

See 1 more Smart Citation

Limplock

Nho

Hao

Leesatapornwongsa

et al. 2013

Proceedings of the 4th Annual Symposium on Cloud Computing

View full text Add to dashboard Cite

We highlight one often-overlooked cause of performance failure: limpware -"limping" hardware whose performance degrades significantly compared to its specification. We report anecdotes of degraded disks and network components seen in large-scale production. To measure the system-level impact of limpware, we assembled limpbench, a set of benchmarks that combine dataintensive load and limpware injections. We benchmark five cloud systems (Hadoop, HDFS, ZooKeeper, Cassandra, and HBase) and find that limpware can severely impact distributed operations, nodes, and an entire cluster. From this, we introduce the concept of limplock, a situation where a system progresses slowly due to the presence of limpware and is not capable of failing over to healthy components. We show how each cloud system that we analyze can exhibit operation, node, and cluster limplock. We conclude that many cloud systems are not limpware tolerant.

show abstract

Section: Discussionmentioning

confidence: 99%

“…All of these lead to performance failures, which is considered a big "nuisance" in largescale system management. Recent work has addressed many sources of performance failures such as heterogeneous systems [30,52], unbalanced resource allocation [29,42,47], software bugs [33], configuration mistakes [15] and straggling tasks [13,22].…”

Section: Introductionmentioning

confidence: 99%

Limplock

Nho

Hao

Leesatapornwongsa

et al. 2013

Proceedings of the 4th Annual Symposium on Cloud Computing

View full text Add to dashboard Cite

show abstract

“…Each iteration of the process retrieves an allocation site node p c from allocList and attempts to find allocation site nodes that are referenced by p c . This is achieved by performing a breath-first traversal of the graph starting from node p c (lines [12][13][14][15][16][17][18][19][20][21][22][23][24]. For each node q d reached during the traversal (line 13), the algorithm inspects each of its outgoing edges.…”

Section: Computing Data Structure Cacheability Measurementsmentioning

confidence: 99%

“…Work by Xu et al [35,36,37,38,34] finds copy-and container-related inefficiencies. Jin et al from [17] studies performance bugs in real-world software systems. These bugs are analyzed to extract efficiency rules, which are then applied to detect problems in other applications.…”

Section: Related Workmentioning

confidence: 99%

Cachetor: detecting cacheable data to remove bloat

Nguyen

2013

Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering

View full text Add to dashboard Cite

Modern object-oriented software commonly suffers from runtime bloat that significantly affects its performance and scalability. Studies have shown that one important pattern of bloat is the work repeatedly done to compute the same data values. Very often the cost of computation is very high and it is thus beneficial to memoize the invariant data values for later use. While this is a common practice in real-world development, manually finding invariant data values is a daunting task during development and tuning. To help the developers quickly find such optimization opportunities for performance improvement, we propose a novel run-time profiling tool, called Cachetor, which uses a combination of dynamic dependence profiling and value profiling to identify and report operations that keep generating identical data values. The major challenge in the design of Cachetor is that both dependence and value profiling are extremely expensive techniques that cannot scale to large, real-world applications for which optimizations are important. To overcome this challenge, we propose a series of novel abstractions that are applied to run-time instruction instances during profiling, yielding significantly improved analysis time and scalability. We have implemented Cachetor in Jikes Research Virtual Machine and evaluated it on a set of 14 large Java applications. Our experimental results suggest that Cachetor is effective in exposing caching opportunities and substantial performance gains can be achieved by modifying a program to cache the reported data.

show abstract

“…I. In a followup work [14] they also describe bugs that manifest as performance slowdowns in concurrent programs. Schaefer et al [15] showed several examples of how sequential refactorings can break concurrent programs.…”

Section: Related Workmentioning

confidence: 99%

CHECK-THEN-ACT Misuse of Java Concurrent Collections

Lin

Dig

2013

2013 IEEE Sixth International Conference on Software Testing, Verification and Validation

View full text Add to dashboard Cite

Concurrent collections provide thread-safe, highly-scalable operations, and are widely used in practice. However, programmers can misuse these concurrent collections when composing two operations where a check on the collection (such as non-emptiness) precedes an action (such as removing an entry). Unless the whole composition is atomic, the program contains an atomicity violation bug.In this paper we present the first empirical study of CHECK-THEN-ACT idioms of Java concurrent collections in a large corpus of open-source applications. We catalog nine commonly misused CHECK-THEN-ACT idioms and show the correct usage. We quantitatively and qualitatively analyze 28 widely-used open source Java projects that use Java concurrency collections -comprising 6.4M lines of code. We classify the commonly used idioms, the ones that are the most error-prone, and the evolution of the programs with respect to misused idioms. We implemented a tool, CTADETECTOR, to detect and correct misused CHECK-THEN-ACT idioms. Using CTADETECTOR we found 282 buggy instances. We reported 155 to the developers, who examined 90 of them. The developers confirmed 60 as new bugs and accepted our patch. This shows that CHECK-THEN-ACT idioms are commonly misused in practice, and correcting them is important.

show abstract

Understanding and detecting real-world performance bugs

Cited by 217 publications

References 56 publications

Limplock

Limplock

Cachetor: detecting cacheable data to remove bloat

CHECK-THEN-ACT Misuse of Java Concurrent Collections

Contact Info

Product

Resources

About