Abstract
According to modern relaxed memory models, programs that contain data races need not be sequentially consistent. Executions that are not sequentially consistent may exhibit surprising behavior such as operations on a thread occurring in a different order than indicated by the source code, or different threads having inconsistent views of updates of shared variables. Java Racefinder (JRF) is an extension of Java Pathfinder (JPF), a model checker for Java bytecode. JRF precisely detects data races as defined by the Java memory model and can thus be used to verify sequential consistency. We describe an extension to JRF, JRF-Eliminator (JRF-E), that analyzes information collected during model checking, specifically counterexample traces and acquiring histories, and provides advice to the programmer on how to eliminate detected data races from a program. Once data races have been eliminated, standard model checking and other verification techniques that implicitly assume sequential consistency can be soundly employed to verify additional properties.
This is a preview of subscription content, log in via an institution to check access.
Similar content being viewed by others
Notes
Among other possibilities, write buffers or values updated by computation() held in registers instead of writing to main memory could cause this effect
Two operations by different threads conflict if they access the same memory location and at least one is a write.
Since Java 1.5, the volatile keyword prevents reordering of memory accesses across accesses to the volatile variable. This is usually implemented using a memory barrier.
JRF actually uses a slightly weaker but still sound notion of correct synchronization.
An object is published when its reference is made visible to other threads. Unsafe publication is a common error that can allow a partially initialized object to be seen by other threads.
Occasionally data races will be deliberately allowed for performance reasons, and because the JMM constrains the values that can be seen through data races enough to avoid type errors and out-of-thin-air values, this is feasible in principle. A well-known example is a racy lazy initialization of the hash code value in the java.lang.String class. Generally, however, reasoning about programs with races is quite difficult and should be considered to be a job for experts only.
Lock-based algorithms including the Race Detector tool in JPF cannot handle these lock-free algorithms and will report false-positives since they approximate the happens-before orders only for locks.
Final fields must be set in the constructor, cannot be modified, and have special semantics in the JMM. Note that the value encapsulated in the atomic object can change, just not the object itself.
Since JPF is working at the bytecode level, accessing a field potentially involves two bytecode instructions—one to get a reference to the object and one to access the field.
Checking of the two conditions in Lemma 4 has been implemented in JRF and the suggestion is made only if the conditions hold. For brevity, the algorithm in Fig. 12 does not include checking these conditions.
Two race traces report the same race when their source and manifest statements are the same.
This assumes worst case scenario based on current JPF trace structure. We can enhance the algorithm by filtering out threadlocal instructions from the trace and managing trace data more wisely but this is left as future work.
The Filter example from Herlihy and Shavit (2008) in Sect. 2 reported 6 races with 863 traces and was successfully analyzed using this incremental mechanism which ran out of memory in standalone mode when tried to analyze all at once. This is more important in user-friendly GUI interface as a future extension to standalone JRF-E, in that the number of traces loadable at the same time was the bottleneck in our experience and it is easy to selectively load minimum necessary information with this mechanism. In addition, it will be also possible to analyze races in parallel and merge the result. These two extension is left as future work.
Java implementations were obtained from the book’s companion web site.
183 different functions are tested in 20 Amino Junit tests.
These races involve features documented as not thread safe, thus indicate bugs in client code, not the Amino library.
Aspects of the JMM constrain the behavior of programs with races. Benign races are those where these constraints guarantee that overall behavior of the program is correct, even with a race. The hashcode variable in the java.lang.String class is the most important example. The hashcode is created lazily, when needed, and is never changed once initialized. The JMM semantics guarantee that the only values seen will be the correct hashcode value, or null, in which case the value will be (re) computed. Since the recomputed value will be the same, it doesn’t affect correctness if the data race allows it to be done more than once.
References
Amino concurrent building blocks (2012). http://amino-cbbs.sourceforge.net/
Aspinall, D., Sevcik, J.: Formalising Java’s data-race-free guarantee. In: TPHOLs 2007. LNCS, vol. 4732, pp. 22–37. Springer, Berlin (2007)
Ball, T., Naik, M., Rajamani, S.K.: From symptom to cause: localizing errors in counterexample traces. In: Principles of Programming Languages, pp. 97–105 (2003)
Basu, S., Saha, D., Smolka, S.A.: Localizing program errors for simple debugging. In: FORTE, pp. 79–96 (2004)
Brun, Y., Ernst, M.D.: Finding latent code errors via machine learning over program executions. In: ICSE, pp. 480–490 (2004)
Burckhardt, S., Musuvathi, M.: Effective program verification for relaxed memory models. In: CAV ’08: Proceedings of the 20th International Conference on Computer Aided Verification, pp. 107–120. Springer, Berlin, Heidelberg (2008)
De, A., Roychoudhury, A., D’Souza, D.: Java memory model aware software validation. In: PASTE ’08: Proceedings of the 8th ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering, pp. 8–14. ACM, New York, NY, USA (2008)
Elmas, T., Qadeer, S., Tasiran, S.: Goldilocks: a race and transaction-aware Java runtime. In: PLDI ’07: Proceedings of the 2007 ACM SIGPLAN Conference on Programming Language Design and Implementation, New York, NY, USA, pp. 245–255. ACM Press, New York (2007)
Flanagan, C., Freund, S.N.: FastTrack: efficient and precise dynamic race detection. In: Programming Language Design and Implementation (2009)
Flanagan, C., Freund, S.N., Yi, J.: Velodrome: a sound and complete dynamic atomicity checker for multithreaded programs. In: PLDI, pp. 293–303 (2008)
Goetz, B., Peierls, T., Bloch, J., Bowbeer, J., Holmes, D., Lea, D.: Java Concurrency in Practice. Addison-Wesley Professional, Reading (2006)
Google concurrent data structures workshop barriers (2012). http://code.google.com/p/concurrent-data-structures-workshop-barriers/
Gosling, J., Joy, B., Steele, G., Bracha, G.: Java Language Specification, 3rd edn. Addison-Wesley, Reading (2005)
Groce, A., Visser, W.: What went wrong: explaining counterexamples. In: SPIN Workshop on Model Checking of Software, pp. 121–135. Springer, Berlin (2003)
Herlihy, M., Shavit, N.: The Art of Multiprocessor Programming. Morgan Kaufmann, San Mateo (2008)
Huynh, T.Q., Roychoudhury, A.: Memory model sensitive bytecode verification. Form. Methods Syst. Des. 31(3), 281–305 (2007)
Java Pathfinder (2012). http://babelfish.arc.nasa.gov/trac/jpf
Kim, K.H., Yavuz-Kahveci, T., Sanders, B.A.: Precise data race detection in a relaxed memory model using heuristic-based model checking. In: Proceedings of the 24th ACM/IEEE Conference on Automated Software Engineering (2009a)
Kim, K.H., Yavuz-Kahveci, T., Sanders, B.A.: Precise data race detection in a relaxed memory model using model checking. Technical report Rep-2009-480, University of Florida (2009b)
Lamport, L.: How to make a multiprocessor computer that correctly executes multiprocess programs. IEEE Trans. Comput. C-28(9), 690–691 (1979)
Manson, J., Pugh, W., Adve, S.V.: The Java memory model. In: POPL ’05: Proceedings of the 32nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, New York, NY, USA, pp. 378–391. ACM Press, New York (2005)
Musuvathi, M., Qadeer, S., Ball, T.: Chess: a systematic testing tool for concurrent software. Technical report MSR-TR-2007-149, Microsoft Research, (2007)
The Java Grande Forum benchmark suite (2012). http://www2.epcc.ed.ac.uk/computing/research_activities/java_grande/index_1.html
Visser, W., Havelund, K., Brat, G.P., Park, S., Lerda, F.: Model checking programs. Autom. Softw. Eng. 10(2), 203–232 (2003)
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
About this article
Cite this article
Kim, K.H., Yavuz-Kahveci, T. & Sanders, B.A. JRF-E: using model checking to give advice on eliminating memory model-related bugs. Autom Softw Eng 19, 491–530 (2012). https://doi.org/10.1007/s10515-012-0109-4
Received:
Accepted:
Published:
Issue Date:
DOI: https://doi.org/10.1007/s10515-012-0109-4