Dynamic%20Analysis%20of%20Multithreaded%20Java%20Programs

1
Dynamic Analysis of Multithreaded Java Programs

• Dr. Abhik Roychoudhury
• National University of Singapore

2
Program Debugging

• Age-old activity
• Simple bug checks handled by compiler type
  errors
• Compiler does not detect violation of behavioral
  invariants
• At control location L1, the value of x cannot be
  0
• Other errors for diff. classes of programs
• Multithreaded (Concurrent or Parallel)
• Real-time

3
Real-time Constraints

• Example
• Data is arriving as a burst every 10 ms
• Every burst is a set of records with a primary
  key
• Sort the primary keys before next dataset arrives
• Need to guarantee that our sorting program always
  completes before 10 ms
• Worst Case Execution Time ? 10 ms
• Worst Case Execution Time should consider all
  possible inputs
• Exponentially many inputs based on permutations.
• Need an efficient analysis technique.

4
Real-time Constraints

• Worst Case Execution Time estimation is a static
  analysis technique.
• Performed at compile-time by analyzing the
  control flow graph of the program
• No data is collected/analyzed during run-time.
• We are trying to prove a property about all
  possible runs of the program.
• Currently working with Li Xianfeng (Ph.D. student)

5
Multithreaded Programs

• Threads do computation AND communication
• e.g. Update of shared resources in a critical
  section
• Communication among threads
• By reading/writing shared variables/objects
• Java programming language
• By explicitly sending/receiving messages
• Message Passing Interface (MPI)
• Multithreaded Program Execution Platform
• Concurrent (Several threads run on single
  processor with a scheduler)
• Parallel (threads run on different processors).

6
Static Analysis and Verification

• Verification of behavioral properties involves
• Constructing a transition system to show the
  state changes as the program executes
• Traversing the transition to check all behaviors.
• Roughly corresponds to an efficient version of
  exhaustive program simulation for all possible
  inputs.
• More complicated if sys. is unbounded in size
• E.g. the number of threads in a program may be
  unbounded, but always finite.
• Currently working with Irina Mariuca Gheorghita
  (Ph.D. student)

7
Dynamic Analysis

• Given an exec. trace of a multi-threaded program
• Analyze the behavior shown in that trace.
• Corresponds to natural notion of debugging
• Debug a program based on a test case (the
  execution trace)
• Lower complexity than verif. techniques ?
• No need to Explore a large state space graph
• But need to collect/store/analyze huge traces ?

8
Cyclic debugging

• Normal debugging activity is cyclic
• Try a test case
• Encounter a bug
• Run the program again with the test case
• Use breakpoints etc. and try to locate bug.
• If not successful, go to 3.
• Multi-threaded programs are non-deterministic
• How to re-generate trace ??

9
Simple Example

• Initially x y 0
• Lock Lock
• x 1 if (x 1)
• Unlock y 1
• else y 2
• Unlock
• Threads communicating via shared variables
• All shared variable accesses are protected

10
Execution trace 1

• User executes as follows
• Thread 1 selected by scheduler.
• Lock x 1 unlock executed by Thread 1.
• Thread 2 selected by scheduler
• Thread 2 executes and y is set to 1
• User suspects the result y 1
• Tries to run the program again with x y 0

11
Execution Trace 2

• Program executes again
• Scheduler now selects Thread 2 first
• If ( x 1) y 1 else y 2 results in y 2
• Thread 1 is executed now and x is set to 1
• User tries to debug based on this trace
• But this is a diff. trace with diff. results.
• Results from the non-determinism of the
  scheduler.
• Non-deterministic exec. in parallel platforms
  also
• Relative processor speeds

12
Problems with Dynamic Analysis

• Multithreaded programs need to store the trace
  (or a portion of it) for future analysis.
• In sequential programs it is enough to store the
  inputs (test-case) generating the trace.
• Dynamic Analysis is w.r.t. a specific trace
• How to generate representative traces ? (How
  to find good test cases ? )
• How to compactly store traces for offline
  analysis?
• How to regenerate partially stored traces ?
• Offline/ Post-mortem analysis techniques

13
Finding representative traces

• Describe the invariant property you want to
  preserve
• At program loc. L1, x should be greater than
  zero
• At all locations, x should be not equal to zero
• Construct a state transition graph of the program
  automatically from the program
• Efficiently traverse the graph to find possible
  violations of the property.

14
Finding representative traces

• If any violation exists, your search produces
• A counterexample trace
• A trace at the end of which the invariant
  property/assertion is violated.
• Use the counterexample trace as a representative
  trace to guide debugging.
• Currently working with Daniel Hogberg (Ph.D.
  student)

15
Compactly storing traces

• Treat the program trace as a string s over a
  pre-defined alphabet.
• Create a hierarchical representation of the
  program trace which is more compact
• (catches repetitions of chunks of code)
• The compact representation should be created
  online, as the program is executing
• We have developed a scheme for compressing Java
  bytecode for multi-threaded programs.
• Working with Wang Tao (Ph.D. student) and Ankit
  Goel (visiting student)

16
Compressed Path - Example
Uncompressed Path 123123
1
Compressed Representation S ? AA A ? 123
2
3
Control Flow Graph
If-then statement
17
Post-mortem analysis of traces

• Compressed traces should be easy to navigate
• Post-mortem analysis should not involve
  decompressing entire trace.
• Useful to detect data races in multi-threaded
  Java programs
• Data races ? Unprotected shared variable accesses
• x 1 x 2
• if (x 1) then S1 if (x 2) then
  S2
• The programmer expects S1, S2 to be executed
• May not happen due to data races.

18
Tracing strategy

• Too costly to track down all shared variable
  operations in a realistic Java program
• Even if the operations are stored compactly, the
  run-time overheads may be too high.
• One possibility is to store only the
  synchronization operations during run-time.
• Regenerate and analyze possible orderings of the
  other communication operations unsynchronized
  shared variable accesses.
• Looking for students in these topics.

19
Relevant Papers

• Compactly Representing Parallel Program
  Executions, (pdf)A. Goel, A. Roychoudhury and T.
  MitraACM Symposium on Principles and Practice of
  Parallel Programming (PPoPP) 2003.
• Specifying Multithreaded Java Semantics for
  Program Verification, (ps, pdf)A. Roychoudhury
  and T. MitraACM/IEEE International Conference on
  Software Engineering (ICSE) 2002, pages 489-499.
• Depiction and Playout of Multi-threaded Program
  Executions, A. Roychoudhury, Submitted for
  publication
• Symbolic Simulation of Live Sequence Charts,
  S. Choudhary, A Roychoudhury and
  RHC Yap, Submitted for publication.

20
My Contact Information

• First two papers available from my web-page.
• http//www.comp.nus.edu.sg/abhik/
• If you are interested in the projects, send
  e-mail
• abhik_at_comp.nus.edu.sg
• dcsar_at_nus.edu.sg