Optimized run-time race detection and atomicity checking using partial discovered types

Abstract

Concurrent programs are notorious for containing errors that are difficult to reproduce and diagnose. Two common kinds of concurrency errors are data races and atomicity violations (informally, atomicity means that executing methods concurrently is equivalent to executing them serially). Several static and dynamic (run-time) analysis techniques exist to detect potential races and atomicity violations. Run-time checking may miss errors in unexecuted code and incurs significant run-time overhead. On the other hand, run-time checking generally produces fewer false alarms than static analysis; this is a significant practical advantage, since diagnosing all of the warnings from static analysis of large codebases may be prohibitively expensive.This paper explores the use of static analysis to significantly decrease the overhead of run-time checking. Our approach is based on a type system for analyzing data races and atomicity. A type discovery algorithm is used to obtain types for as much of the program as possible (complete type inference for this type system is NP-hard, and parts of the program might be untypable). Warnings from the typechecker are used to identify parts of the program from which run-time checking can safely be omitted. The approach is completely automatic, scalable to very large programs, and significantly reduces the overhead of run-time checking for data races and atomicity violations.

An Integrated Framework for Checking Concurrency-Related Programming Errors

“…The average slowdown is 16.5x, which is about 4 times as our previous purely dynamic approach [11]. Hence, the hybrid approach reports fewer false positives than the previous static approaches [7,1], and fewer false negatives (i.e., missed errors) than the previous dynamic approaches [6,12,11], at the sacrifice of performance. Figure 2 shows the architecture of our tool, HAVE, which consists of five components.…”

“…Static analysis can be used to reduce the overhead of dynamic analysis. For example, static analysis can show that some statements are not involved in any data races or atomicity violations and hence do not need to be instrumented; this can significantly reduce the overhead of dynamic analysis by up to a factor of 20 [1]. Conversely, dynamic analysis can help static analysis by providing more accurate runtime information.…”

HAVE: Detecting Atomicity Violations via Integrated Dynamic and Static Analysis

“…The experiments show that the hybrid approach reports fewer false positives than the previous static approaches [9,1], and fewer false negatives (i.e., missed errors) than the previous dynamic approaches [6,20,19].…”

“…We use Java reflection mechanism to dynamically update the field. An object o becomes shared in the following scenarios: (1) o is stored in a static field or a field of a shared object; (2) o is an instance of a thread and the thread is started; (3) o is referenced by a field of another object o , and o becomes shared (this leads to cascading sharing); (4) o is passed as an argument to a native method that may cause it to be shared.…”

“…Agarwal, Sasturkar, Wang, and Stoller used static analysis to reduce the overhead of the reduction-based algorithm [14] and the block-based algorithm [1]. JPredictor uses static analysis to improve the accuracy of the dependency relation used in dynamic checking for potential concurrency errors, including atomicity violations [3].…”