1. Asynchronous Assertions Eddie Aftandilian and Sam Guyer Tufts University Martin Vechev ETH Zurich and IBM Research Eran Yahav Technion

2. OOPSLA, October 25-27, 20112 Assertions are great Assertions are not cheap Cost paid at runtime Limits kinds of assertions Our goal Support more costly assertions (e.g., invariants) Support more frequent assertions Do it efficiently Motivation

3. OOPSLA, October 25-27, 20113 Asynchronous assertions Evaluate assertions concurrently with program Lots of cores (more coming) Enable more expensive assertions Thank you. Questions? Idea Two problems What if program modifies data being checked? When do we find out about failed assertions?

4. OOPSLA, October 25-27, 20114 Run assertions on a snapshot of program state Guarantee Get the same result as synchronous evaluation No race conditions How can we do this efficiently? Solution

5. OOPSLA, October 25-27, 20115 Incremental construction of snapshots (copy-on-write) Integrated into the runtime system (Jikes RVM 3.1.1) Supports multiple in-flight assertions Our implementation

6. OOPSLA, October 25-27, 20116 Overview Program threadChecker thread a = assert(OK()); o.f = p; if (o.f == …); OK() { return res; } wait(); b = a.get();... if (b) {.....wait.. Needs to see old o.f

7. OOPSLA, October 25-27, 20117 Main threadChecker thread Key o.f = p; if (o.f == …) for each active assertion A if o not already in A’s snapshot o’ = copy o mapping(A, o) := o’ modify o.f if o in my snapshot o’ = mapping(me, o) return o’.f else return o.f Write BarrierRead Barrier

8. OOPSLA, October 25-27, 20118 How do we know when a copy is needed? Epoch counter E Ticked each time a new assertion starts On each object: copied-at timestamp Last epoch in which a copy was made Write barrier fast path: If o.copied-at < E then some assertion needs a copy How do we implement the mapping? Per-object forwarding array One slot for each active assertion Implementation

9. OOPSLA, October 25-27, 20119 Synchronization Potential race condition Checker looks in mapping, o not there Application writes o.f Checker reads o.f Lock on copied-at timestamp Cleanup Zero out slot in forwarding array of all copied objects We need to keep a list of them Copies themselves reclaimed during GC Tricky bits

10. OOPSLA, October 25-27, 201110 Snapshot sharing All assertions that need a copy can share it Reduces performance overhead by 25-30% Store copy in each empty slot in forwarding array (for active assertions) Avoid snapshotting new objects New objects are not in any snapshot Idea: initialize copied-at to E Fast path test fails until new assertion started Optimizations

11. OOPSLA, October 25-27, 201111 Waiting for assertion result Traditional assertion model Assertion triggers whenever check completes Futures model Wait for assertion result before proceeding Another option: “Unfire the missiles!” Roll back side-effecting computations after receiving assertion failure Interface

12. OOPSLA, October 25-27, 201112 Idea: We know this can catch bugs Goal: understand the performance space Two kinds of experiments Microbenchmarks Various data structures with invariants Pulled from runtime invariant checking literature pseudojbb Instrumented with a synthetic assertion check Performs a bounded DFS on database Systematically control frequency and size of checks Evaluation

13. OOPSLA, October 25-27, 201113 Performance When there’s enough work 7.2-7.5x speedup vs. synchronous evaluation With 10 checker threads Ex. 12x sync slowdown  1.65x async When there’s less work: 0-60% overhead Extra memory usage for snapshots 30-70 MB for JBB (out of 210 MB allocated) In steady state, almost all mutated objects are copied Cost plateaus Key results

14. OOPSLA, October 25-27, 201114 Pseudojbb graph schema Assertion workload 1.0 Sync Async Application waiting Normalized runtime Snapshot overhead Overloaded OK

15. OOPSLA, October 25-27, 201115 Fixed frequency, increasing cost

16. OOPSLA, October 25-27, 201116 Fixed frequency, increasing cost, zoomed

17. OOPSLA, October 25-27, 201117 Fixed frequency, increasing cost

18. OOPSLA, October 25-27, 201118 Concurrent GC Futures Runtime invariant checking FAQ: why didn’t you use STM? Wrong model We don’t want to abort In STM, transaction sees new state, other threads see snapshot Weird for us: the entire main thread would be a transaction Related work

19. OOPSLA, October 25-27, 201119 Execute data structure checks in separate threads Checks are written in standard Java Handle all synchronization automatically Enables more expensive assertions than traditional synchronous evaluation Thank you! Conclusions

20. OOPSLA, October 25-27, 201120

21. OOPSLA, October 25-27, 201121 Snapshot volume

22. OOPSLA, October 25-27, 201122 Sharing snapshots

23. OOPSLA, October 25-27, 201123 Snapshot overhead

24. OOPSLA, October 25-27, 201124 Fixed cost, increasing frequency

25. OOPSLA, October 25-27, 201125 Fixed cost, increasing frequency, zoomed

26. OOPSLA, October 25-27, 201126 Copy-on-write implementation a obj a b b c

27. OOPSLA, October 25-27, 201127 Safe Futures for Java [Welc 05] Future Contracts [Dimoulas 09] Ditto [Shankar 07] SuperPin [Wallace 07] Speculative execution [Nightingale 08, Kelsey 09, Susskraut 09] Concurrent GC Transactional memory Related work