Download - Model Checking Java Programs
![Page 1: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/1.jpg)
Model Checking Java Programs
David Park, Ulrich Stern, Jens Skakkebaek, and David L. Dill
Stanford University
![Page 2: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/2.jpg)
2
Introduction
Can model checking be usefully applied to programs?
• Model checking background• Model checking & software• A Java model checker• Research directions
![Page 3: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/3.jpg)
Background on model checking
![Page 4: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/4.jpg)
4
Model Checking
• “Model checking” analyzes the reachable state space of a system for certain properties.
• Analysis may – enumerate states and – may also look for paths (e.g., unfair cycles)
• State set representation can be– explicit (e.g., hash table of states) [E.g., SPIN, Mur]– symbolic (e.g., a Boolean function represented as a
Boolean decision diagram [BDD]) [SMV, nuSMV, VIS]
![Page 5: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/5.jpg)
5
Explicit-state vs. symbolic
Explicit state model checking has several advantages:
• More predictable (hard to diagnose reasons for BDD blowup).
• Avoid difficulties of translating everything to Boolean functions.
• Easier to deal with dynamic features of software (e.g. heap-allocated objects).
![Page 6: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/6.jpg)
6
Trivial Mur example
One state variable, two rules: count > 0 --> count := count - 1; count < 10 --> count := count + 1;
0 1 2 3 10 . . .
![Page 7: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/7.jpg)
7
Basic explicit model checking
On-the-fly search procedure
Initialize: Queue is empty; Table is empty; push s0 onto Queue;
Loop: while Queue not empty do remove s from Queue;
if s is NOT already in Table then enter s in Table; for all enabled rules r at s do
s’ = succ(s,r); insert s’ into Queue;
![Page 8: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/8.jpg)
8
“Sweet spot” for model checkingDesigns that are control-dominated and nondeterministic
(Nondeterminism stems from concurrency and environmental behavior)
– Designers can’t foresee all cases and interactions– Directed or random testing gets poor coverage
(there aren’t even good coverage metrics)
– Simple static analysis methods either miss too many bugs or report too many false errors.
– Even running a prototype results in infrequent, unrepeatable, hard-to-diagnose failures.
![Page 9: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/9.jpg)
9
Perspectives on model checking
• As a testing method– Model checking is more expensive and more thorough– “Tests” generated automatically– States are saved to avoid redundant work
• As a static analysis method– Model checking enumerates paths more precisely than
traditional static analysis– Hence, it is more accurate and more costly.
![Page 10: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/10.jpg)
10
The three big problems
• Computational complexity (e.g., the state explosion problem)
• Finding properties to check• Describing/constraining environment
![Page 11: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/11.jpg)
Model checking of software
![Page 12: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/12.jpg)
12
The Key Requirement
A new verification technique will not be adopted unless the benefits
outweigh the costs.
![Page 13: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/13.jpg)
13
Special problems of software
• Bugs are less expensive in software than hardware or protocols– Field upgrades are often relatively inexpensive – Dynamic structures– Heap– Recursion– Dynamically allocated threads
• Large state spaces• Complex environment
– OS– Hardware– User
![Page 14: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/14.jpg)
14
Bugs are inexpensive
Cost of verification must be minimized– Verifying code instead of high-level specs reduces
specification burden– Checking implicit properties (e.g., deadlock) reduces
cost
Other costs must be displaced (e.g., manual testing)
Target applications that have relatively high cost– Safety critical– Embedded real-time systems– Other cases: security?
![Page 15: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/15.jpg)
15
Dynamic stuff
HeapRecursionDynamically allocated Threads
Eliminate artificial limitations of existing model checkers – Allow dynamic arrays– No a priori limit on state space, but that’s ok.
![Page 16: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/16.jpg)
16
Large state spaces
Large state spaces– Software complexity is not highly constrained by
physical resources
Target embedded applications, which are somewhat resource-constrained (but less so each day).
Use available model checking optimizations
![Page 17: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/17.jpg)
17
Complex environment
OSHardwareUser
Hope that detailed constraints aren’t needed
Bite the bullet and write specifications
![Page 18: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/18.jpg)
A Java model checker
![Page 19: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/19.jpg)
19
Java Model checking
Why Java?
• Lots of interest• Well-defined thread model• Possibly to be used for embedded real-time
applications in future.
![Page 20: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/20.jpg)
20
Value of model checking for Java
• Concurrency problems still very hard to test and debug– Nondeterminism from scheduling– Seemingly reliable applications may break when on
new hardware, JVM, or under different scheduling load.– Unpredictable, non-repeatable failures.
• Other sources of nondeterminism– Interactions with user, system calls
![Page 21: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/21.jpg)
21
Status of project
• Mostly an integration of existing ideas• Prototype is implemented• Implements a large subset of Java including
most advanced features of Java.– Inheritance, overriding, overloading, exception
handling
• Can deal with small programs written by others– Can’t deal with native code in libraries, etc.
![Page 22: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/22.jpg)
22
Properties checked
Goal: Keep specification simple– Check properties that don’t have to be explicitly
specified– Programmers are comfortable with in-line assertions.
Checker looks for – deadlock– assertion failures – selected exceptions: array bounds, run-time type
errors.
. . . more coming soon.
![Page 23: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/23.jpg)
23
Translation strategy
• Translate statements to SAL guarded commands– Nondeterminism of guarded commands used to model
scheduler, possible results of API calls.
• Implement JVM run-time in SAL– Heap, stack, are implemented as dynamic arrays– Classes, stack frames implemented as records
![Page 24: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/24.jpg)
24
Processing steps
JavaByte-code
JavaByte-code JimpleJimple SAL
Level 1SAL
Level 1
SAL Level 0SAL
Level 0 C++C++ Model CheckerModel
Checker
JavaProgram
ErrorTrace
![Page 25: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/25.jpg)
25
Java to SAL translation
– Jimple statements SAL guarded commands
Example:
i0 = 1
is translated into
(PC[TID] = label_0) --> next(Stack)[TID][SP].localVariables.i0 = 1; next(PC)[TID] = label_1;
where
PC: program counterTID: thread identifier of current threadlabel_0: SAL label of the statement i0 = 1SP: stack pointer
![Page 26: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/26.jpg)
26
Optimization: Atomic Blocks
• Idea (Bruening, 1999): execute large blocks of code without interleaving at the statement level.– Don’t need to save or copy intermediate states (just
save state at end of block).– Avoid state explosion from fine-grained interleaving.
vs.
![Page 27: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/27.jpg)
27
Atomic Blocks
• Assumption: all accesses to shared variables are locked.– This can and should be checked during verification using
same method as in Eraser.
• Blocks are broken immediately after “unlock” events.– Not necessary to break at “lock”. There may be multiple
locks and lots of other statements in the block.– This would miss deadlocks,– . . . but there is a more sophisticated deadlock check
based on circular wait conditions that catches all of them.
• If a block fails to acquire a lock, it is aborted
![Page 28: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/28.jpg)
28
Atomic Blocks
• Model checker does the optimization on-the-fly– execution continues until unlock. Then state is saved
and other threads can be executed.
• This is a special form of persistent set reduction (Wolper and Godefroid).
![Page 29: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/29.jpg)
29
Savings from atomic blocks
CS193K ReaderWriter
CS193KTurnDemo
NASA’s Classic
NASA’s Ksu_pipe
261,838
528
26,145
166
45,924
143
3,990,883
4991
1,030,130
1,356
68,715
236
118,047
234
14,022,723
15,762
1.0
496
1.0
158
1.0
321
1.0
800
442s
1.54s
30.4s
2.40s
46.6s
2.11s
6401s
11.8s
Example Blocks? States Rules Time Reduction
N
Y
N
Y
N
Y
N
Y
![Page 30: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/30.jpg)
30
Optimization: Hash Compaction• Idea: Instead of saving (large) states in state table,
store (small) signatures (Wolper&Leroy, Stern&Dill).• Tradeoff: May result in missed errors because state
search falsely thinks it has seen a state before.• Probability of missed error can be bounded
– 5-byte signatures, 80 million states: P(omission) < 0.13%.
• Outcomes:– Error found (guaranteed correct)– Ran out of space, no errors (inconclusive)– Searched all states, no errors (almost guaranteed correct).
![Page 31: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/31.jpg)
31
Related work
• Eraser [Savage et al., 1997]– Checks unlocked variables, but doesn’t replace test
generation.
• Verisoft [Godefroid, 1996], Rivet [Bruening, 1999], Stoller 2000– Systematically exercises design, but doesn’t check
previously visited states (may do redundant work)
• Java PathFinder (NASA)– Similar goals, different optimizations, no SAL, no C++
• dSPIN - dynamic data structures in SPIN (but no special optimizations)
![Page 32: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/32.jpg)
The Future
![Page 33: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/33.jpg)
33
The three big problems (again)
• Computational complexity (e.g., the state explosion problem)
• Finding properties to check• Describing/constraining environment
More research is needed on all of these problems, in addition to integrating existing techniques.
![Page 34: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/34.jpg)
34
Computational complexity
This problem requires an assault from many directions.• Reduce the problem before model checking
– Slicing based on property being checked.– Data and control abstraction.– E.g., Bandera system.
• Additional model checker optimizations– Better persistent set reductions– Heap-based optimization
• symmetry• early garbage collection
• Partial verification– Provide guidance to most interesting parts of state space
![Page 35: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/35.jpg)
35
Finding properties to check
• Race detection– “Eraser” model - but requiring Java locks on all shared
variables is neither necessary nor sufficient• Misses higher-level locking constructs• Misses higher-level atomicity requirements• Possibilities of new models: lock ordering, “happens before”
• Check wider range of exceptions• Specify and check requirements of standard
libraries
![Page 36: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/36.jpg)
36
Environmental specification
• Write more robust programs– Detect and report bad environment behavior– Code to do this can be used by verifier to exclude false
errors
• Specify reusable constraints for common cases (e.g., standard libraries)
• Slicing and abstraction can immunize verification from irrelevant environment problems.
Better solutions are needed.
![Page 37: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/37.jpg)
37
Model checking & static analysis
• How can static analysis help with the previous problems?
• Should model checking be integrated with (or absorbed into) static analysis?
![Page 38: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/38.jpg)
38
Feasibility of model extraction
• Work with Dawson Engler and David Lie of Stanford
• FLASH multiprocessor cache coherence protocols implemented in C– Weird resource constraints– Very hard to debug when it crashes– 10-30K lines of code– Code has been worked over very thoroughly
![Page 39: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/39.jpg)
39
Feasibility of model extraction
• Used xg++ compiler to extract a Mur model– xg++ allows user to write state machines that traverse
C++ data flow graph– Identifies messages, protocol state transitions– Ignores everything else (ad hoc slicing)– Method is specific to these protocols– Method is neither sound nor complete
• 9 Bugs found
![Page 40: Model Checking Java Programs](https://reader036.vdocuments.us/reader036/viewer/2022081519/56812fc9550346895d95492e/html5/thumbnails/40.jpg)
40
Web page
http://verify.stanford.edu