1. Specifying Multithreaded Java semantics for Program Verification Abhik Roychoudhury National University of Singapore (Joint work with Tulika Mitra)

2. ICSE 2002, Orlando FL2 Java Multithreading Threads communicate via shared variables Threads run on uni- or multi-processors Semantics given as abstract rules : Java Memory Model (JMM) Supports locking of shared variables via synchronized statements Locking may be avoided ….

3. ICSE 2002, Orlando FL3 Shared variable access without locks Initially : A = 0, B = 0 B = 1; A = 1; while (A != 1) {}; return B || Expected returned value = 1 Locks not used, but using A as flag.

4. ICSE 2002, Orlando FL4 What may happen Returned value = 0 A= 1 return B B = 1 May happen if ….. Threads are executed on different processors. B = 1; A = 1; while (A != 1) {}; return B ||

5. ICSE 2002, Orlando FL5 Sequential Consistency || Op1; Op2; Op’ ; Op’’ ; Programmer expects statements within a thread to complete in program order: Sequential Consistency I.Each thread proceeds in program order II.Operations across threads are interleaved Op1 Op’’ Op2 Op’ violates SC

6. ICSE 2002, Orlando FL6 Is this a problem ? Programmers expect SC Verification techniques assume SC execution SC not guaranteed by execution platforms Not demanded by Java language spec. Unrealistic for any future spec. to demand YES !!

7. ICSE 2002, Orlando FL7 Organization Shared variable access without locks Candidate solutions Specifying the Java Memory Model (JMM) Using JMM for verification

8. ICSE 2002, Orlando FL8 1. Program with caution Always synchronize (and acquire lock) before writing a shared object For these programs, any execution is SC Unacceptable performance overheads for low-level libraries Software libraries from other sources cannot be guaranteed to be properly synchronized

9. ICSE 2002, Orlando FL9 2. Change the Semantics Current semantics called Java Memory Model (JMM). Part of Java language spec. Weaker than Sequential Consistency. Specifies which re-orderings are allowed within a thread. Currently being considered for revision Existing/future JMM bound to be weaker than SC – Does not solve the problem

10. ICSE 2002, Orlando FL10 3. Use the semantics Develop a formal executable description of the Java Memory Model Use it for static checking of programs JMM captures all possible behaviors for any implementation – Platform independent reasoning Adds value to existing program verification techniques

11. ICSE 2002, Orlando FL11 Organization Shared variable access without locks Candidate solutions Specifying the Java Memory Model (JMM) Using JMM for verification

12. ICSE 2002, Orlando FL12 JMM Overview Each shared variable v has A master copy A local copy in each thread Threads read and write local/master copies by actions Imposes ordering constraints on actions Constraints are informal and declarative Hard to understand !!

13. ICSE 2002, Orlando FL13 JMM Actions Master copy of v read(v,t) <load(v,t) write(v,t)>store(v,t) Actions invoked by Program Execution: use/assign(t,v) Read from/ Write into local copy of v in t lock/unlock(t) Acquire/Release lock on shared variables Local copy of v in t

14. ICSE 2002, Orlando FL14 Formal Specification Asynchronous concurrent composition Th 1 || Th 2 || … || Th n || MM Local state of each thread modeled as cache ( Local copy, Stale bit, Dirty bit ) Queues for incomplete reads/writes Local state of MM ( Master copies, Lock ownership info )

15. ICSE 2002, Orlando FL15 Specifying JMM Actions Each action is a guarded command G  B Only 8 actions capture all the rules. Example: Use of variable v by thread t  stale[t,v]  return local_copy[t,v] Applicability of action stated as guard In rule-based description, several rules determine the applicability

16. ICSE 2002, Orlando FL16 Understanding JMM assign(t, v) < load(t,v)  assign(t,v) < store(t,v) < load(t,v) A store must intervene between an assign and a load action for a variable v by thread t

17. ICSE 2002, Orlando FL17 Understanding JMM assign(t, v) < store(t,v) < load(t,v)  assign(t,v) < store(t,v) < write(t,v) < read(t,v) < load(t,v) assign(t,v) < load(t,v)  read < assign <load is not possible. We specify assign(t,v) : empty(read_queue[t,v]) -> ….

18. ICSE 2002, Orlando FL18 Executable model Java threads invoke use,assign,lock,unlock Threads block if the next action not enabled To enable these, store,write,load,read are executed in any order provided guard holds Example: To enable assign, a load is executed (if there was an earlier read) Proof of equivalence between executable and rule-based JMM.

19. ICSE 2002, Orlando FL19 Other JMM Features Executable model also captures: Volatile variables : Every access of these variables accesses master copy Prescient stores: Writing master copy ahead of local copy Waiting and Notification Modeled by additional guarded commands.

20. ICSE 2002, Orlando FL20 Organization Shared variable access without locks Candidate solutions Specifying the Java Memory Model (JMM) Using JMM for verification

21. ICSE 2002, Orlando FL21 Verifying Unsynchronized Code assign(B,1) assign(A,1) While (use(A) !=1){} use(B) || use/assign invoke corresponding guarded commands load/store/read/write executed to enable use/assign Exhaustive state space exploration shows use(B) may return 1 or 0

22. ICSE 2002, Orlando FL22 Program verification Composing executable JMM allows search The state space explosion problem  Most Java programs are “properly synchronized” and hence SC execution Unsynchronized code appears in low-level fragments which are frequently executed These programs are small, so …

23. ICSE 2002, Orlando FL23 One possibility User chooses one program path in each thread (Creative step) Exhaustively check all possible execution traces from chosen program paths (Automated state space exploration: Can verify invariants) Choosing program paths requires understanding source code, not JMM

24. ICSE 2002, Orlando FL24 Case Study: Double Checked Locking Idiom for lazy instantiation of a singleton Check whether garbage data-fields can be returned by this object initialization routine Verification by composing the JMM reveals: Incompletely instantiated object can be returned Due to re-ordering of writes within constructor Detected by prototype invariant checker in 0.15 sec

25. ICSE 2002, Orlando FL25 Summary Executable specification of Multithreaded Java semantics Using the specification for checking multithreaded programs Similar approach has been studied before in the context of hardware multiprocessors How to correct the bugs found (the harmful re-orderings) ?