Karl Lieberherr PhD work of Ahmed Abdelmeged Northeastern University

1. Better Blame Assignment for State and Behavioral AssertionsApplied to Cache-Based Optimization Aspects Karl Lieberherr PhD work of Ahmed Abdelmeged Northeastern University Safe Cache-Based Optimization Aspects

2. Problem • Take your favorite Algorithms text book: • Typical pattern • Here is the elegant algorithm: … • To make it run (asymptotically) faster we make the following modifications which don’t affect the correctness but they need a bit more memory: … • We formalize the code for the modifications by developing a cache-based aspect model that makes it easier to develop optimized code. Safe Cache-Based Optimization Aspects

3. Pattern applies to many algorithms • Topological ordering • Closest pair • Dijkstra’s shortest path • Union-find • Prim • Kruskal, etc. Safe Cache-Based Optimization Aspects

4. Topological Ordering • Input: DAG G=(V,E) • Output: Topological Ordering of G • use several slides Safe Cache-Based Optimization Aspects

5. Example: Topological OrderingKleinberg/Tardos • Algorithm: The inductive proof contains the following algorithm: • TopOrder(G) = … TopOrder(G-{v}) … • Running time O(n2) • We can achieve a running time of O(m+n) using the same high-level algorithm … • find nodes to delete more efficiently Safe Cache-Based Optimization Aspects

6. Source nodes • Crucial operation: Graph.sourceNodes() (nodes without predecessors) • TopOrder(G) = … TopOrder(G-{v}) … • TopOrder(G) = … choose v in sourceNodes(); TopOrder(G-{v}) … • sourceNodes is computed repeatedly: wasteful. • Incremental: when v is deleted, how does sourceNodes() change? Safe Cache-Based Optimization Aspects

7. Outline • Introduction • Algorithm textbook deficiency: ad-hoc optimization • Contracts for Aspects • state assertions • behavioral assertions • novel feedback based on dynamic checking • most recent deterioration • advice configuration exploration • Domain-Specific Aspects • Cache-Based Optimization Aspect Model • Conclusions Safe Cache-Based Optimization Aspects

8. Safe Cache-Based Optimization Aspects

9. sourceNodes() Safe Cache-Based Optimization Aspects

10. Graph Safe Cache-Based Optimization Aspects

11. Node Safe Cache-Based Optimization Aspects

12. Caching Aspect cache SNodes[Graph g => List(Node)] memoizes Graph.sourceNodes() in Graph.topologicalOrder() @Maintenance for g.nodes(remove(v)) for (Node succ:((Node)v).getSuccessors()){ if (SNodes.g.predecessorsOf(succ)==0){ SNodes.value.add(succ); } } Safe Cache-Based Optimization Aspects

13. Asymptotic Improvement Safe Cache-Based Optimization Aspects

14. Use of caches • E.g., memoization: avoid running the same computation more than once: time-memory tradeoff. • Our Goal: improve asymptotic running time or lower constants. Strive for practical tool. • Express optimization as aspect • check safety dynamically • Other uses of caches • speed-up subsequent computations • reorganize computations • It is unlikely that caching techniques can be automated. Safe Cache-Based Optimization Aspects

15. Outline • Introduction • Algorithm textbook deficiency: ad-hoc optimization • Contracts for Aspects • state assertions • behavioral assertions • novel feedback based on dynamic checking • most recent deterioration • advice configuration exploration • Domain-Specific Aspects • Cache-Based Optimization Aspect Model • Conclusions Safe Cache-Based Optimization Aspects

16. Polya’s Inventor’s Paradox • Need aspects for cache-based optimization. Want to facilitate development of aspects: need good blame assignment for valid-cache invariants and purity condition violations for optimization aspects. • Solve the more general problem: Blame assignment for state invariants and behavioral invariants violations. Safe Cache-Based Optimization Aspects

17. Contracts for Aspects • In the presence of AspectJ-like aspects, developers must reason globally about certain properties of both the base program as well as aspects. • Alternatively, developers can assert such properties at runtime. However, when these assertions fail, it can be hard to point to the potential causes of failure especially those not on the call stack at the time of failure. Safe Cache-Based Optimization Aspects

18. Contracts for Aspects • The ordering of advice within the same aspect, the precedence of aspects, and the existence of other aspects can cause the failure of assertions. • We assume here that removing an aspect cannot cause a failure of some assertion because aspects are not meant to fix bugs. • If changing any of these three factors causes the assertion to seize failing, then we blame that factor. Safe Cache-Based Optimization Aspects

19. Contracts for Aspects • Advice configuration can cause assertions to fail. • Advice configuration refers to the ordering of advice within the same aspect, the precedence of aspects, and the set of included aspects. • In a weaving based AOP systems such as AspectJ, not all the components of advice configuration have a runtime representation.  Safe Cache-Based Optimization Aspects

20. Contracts for Aspects • Assertion violated • Try different configurations (helps with behavioral assertions) • different precedence ordering • different advice orderings • using subsets of aspects • If one configuration succeeds in not violating assertion: useful information that might solve problem. • Monitoring (makes program very slow during debugging) • hope to use static techniques Safe Cache-Based Optimization Aspects

21. Contracts for Aspects: Monitoring • State-Assertion violated • Most recent deterioration point for state-assertion Safe Cache-Based Optimization Aspects

22. Contracts for Aspects • Aspect-Oriented Software Development • Programmers write assertions for aspects • behavioral assertions • state assertions • Configuration exploration and most recent deterioration join points help programmers to debug their aspects. • In some cases, assertions are easy to write. Safe Cache-Based Optimization Aspects

23. Problems of Cache-Based Optimization Aspects • Make sure that cache is maintained correctly after an invalidation before it is read again. • Use assertions. • For state assertions • blame the stack trace at the join point failing a test. • at the most recent deterioration join point. That is the joinpoint before which the assertion succeeded and after which it failed. Safe Cache-Based Optimization Aspects

24. Two Kinds of Assertions • State Assertions • Example: Data Structure Consistency • Usage: Tested at specific joinpoints • Blame • jp failing test • most recent deterioration jp • Behavioral Assertions • Example: Joinpoint purity • Usage: Testing is Activated/Deactivated at specific joinpoints • Blame • jp failing test Safe Cache-Based Optimization Aspects

25. Aspect Interactions • Only blame aspect interactions that would have broken an aspect contract. Safe Cache-Based Optimization Aspects

26. Outline • Introduction • Algorithm textbook deficiency: ad-hoc optimization • Contracts for Aspects • state assertions • behavioral assertions • novel feedback based on dynamic checking • most recent deterioration • advice configuration exploration • Domain-Specific Aspects • Cache-Based Optimization Aspect Model • Conclusions Safe Cache-Based Optimization Aspects

27. Domain Specific Aspect Languages • Our goal: safer development. When something is wrong with the aspect, blame will be assigned properly. • Reusable aspect contracts. Expressed with annotations. Lightweight Domain Specific Aspect Languages (LDASL). • minimal effort to learn Safe Cache-Based Optimization Aspects

28. Reusable aspect contracts • Cache-based optimization aspects • serve as basis for constructing a LDASL for this family of aspects. Safe Cache-Based Optimization Aspects

29. Domain Specific Aspect Language • In style of COOL and RIDL. • It is a domain-specific aspect-oriented programming language. Two views: • restriction of AspectJ (annotations) • high-level language that translates into restricted subset • Restriction helps with finding good cache-based optimizations. Some automation of how to optimize because we know which blame to avoid. • Restriction helps with correctness. • Continuation of Crista Lopes’ work started in 1992. Safe Cache-Based Optimization Aspects

30. Recipe for domain-specific aspects • Ease the development process via • Aspect contracts for an accurate blame assignment • Abstraction of repetitive contract cliches, advice etc. into annotations. •  We develop the language for writing the contracts. Using our cache-based optimization algorithms as a test harness (Topological ordering, Dijkstra, Closest Pair). Safe Cache-Based Optimization Aspects

31. Outline • Introduction • Algorithm textbook deficiency: ad-hoc optimization • Contracts for Aspects • state assertions • behavioral assertions • novel feedback based on dynamic checking • most recent deterioration • advice configuration exploration • Domain-Specific Aspects • Cache-Based Optimization Aspect Model • Conclusions Safe Cache-Based Optimization Aspects

32. Design Structure Matrix Base: Program to be optimized. iMethods: methods with cache support Rest: rest of base program Opt: Optimization aspect Safe Cache-Based Optimization Aspects

33. Model • Cache declaration • Three kinds of advice • maintenance • compensates for destructive updates • management • storing certain subcomputations • helper • make more amenable to cache-based optimization Safe Cache-Based Optimization Aspects

34. Model • A helper advice is an around advice that • has a pure body. • advises pure join points. • A maintenance advice is either a before or after advice that can only mutate cache entries in its aspect. • A management advice is either a before or after advice that can only mutate the cache in its aspect (to add new entries). Safe Cache-Based Optimization Aspects

35. Motivation for Helper Advice • Requires invention. • Use Dijkstra’s shortest path algorithm as example. Safe Cache-Based Optimization Aspects

36. Optimization Opportunities • selectMin(q,distance) is invoked several times in the main loop of the algorithm with the same arguments. • Chance to memoize selectMin. • But arguments are destructively updated by • q.remove(u) • distances.put(v,alt) • Maintenance advice to restore cache entries? Safe Cache-Based Optimization Aspects

37. Optimization Opportunities • Unfortunately, selectMin is not amenable to incrementalization under q.remove(u). • The old minimum is not useful in computing the new minimum after the old minimum has been removed. • There are no subcomputations that can be productively memoized. • Need helper advice to make algorithm amenable to productive memoization. Safe Cache-Based Optimization Aspects

38. Helper Advice • Replace selectMin with a subcomputation that is amenable to either memoization or incrementalization under some destructive updates. • Replace selectMin with heap construction followed by heap.findMin(). • Is amenable to incrementalization under both update operations. Safe Cache-Based Optimization Aspects

39. Pure Computation • no destructive updates: it never destructively updates any object reachable (has-a) from a variable in the base program environment • no IO • no exceptions Safe Cache-Based Optimization Aspects

40. Pure Aspects • An aspect is pure if • all advice are purse computations • around advice can only replace join points of pure computations Safe Cache-Based Optimization Aspects

41. Validity of cache entry • Entry is valid when it is first added to the cache. • Validity after maintenance. Entry a->v is valid after the object graph rooted at v is destructively updated in the control flow of some maintenance advice. • Entry is retrieved either before any invalidation or after maintenance (safety condition). Safe Cache-Based Optimization Aspects

42. Introduction • Optimized algorithm/program (OptAlgo) is often more complex than its unoptimized version (Algo). • Important to prove/argue that • OptAlgo is observationally equivalent to Algo and • OptAlgo outperforms Algo on some inputs. Safe Cache-Based Optimization Aspects

43. Introduction • Algo as specification and OptAlgo as implementation. • Such proofs/arguments can be cumbersome/tricky if both Algo and OptAlgo are written in a general purpose programming language such as Java. Safe Cache-Based Optimization Aspects

44. Introduction • Instead of Algo and OptAlgo, use Algo and Opt+Algo, where Algo is written in Java and Opt is an aspect is written in an aspect oriented programming language such as AspectJ. • Need to prove/argue that Opt is harmless (i.e., Opt can never change the final value returned by Algo, if they terminate). Safe Cache-Based Optimization Aspects

45. Introduction • Again, this does not help with the proof/argument much and can even make it worse. • But, for a cache-based optimization aspect (an optimization aspects trading space for time) we can ease its proof/argument if we express it in a  some restricted style/model/language. Safe Cache-Based Optimization Aspects

46. Motivation for Model • We developed a model for domain specific aspect-oriented programming language for expressing cache-based optimization aspects. Our model is based on the following cache-based optimization patterns: Safe Cache-Based Optimization Aspects

47. Motivation for Model 1. Memoization. 2. Memoization + maintenance under destructive updates to the keys of entries in the cache. 3. Application specific optimization. These are either:      3.1 Memoization + maintenance under certain functional updates to the keys of entries in the cache.      3.2 modification of the base program to make it more amenable to optimization + one of the aforementioned patterns. Safe Cache-Based Optimization Aspects

48. Model • We model a cache-based optimization aspect as • a pointcut identifying the memoized method, • a number of • maintenance, • management and • helper advice. Safe Cache-Based Optimization Aspects

49. Local Reasoning Based on these restrictions, the correctness proof/argument for the overall aspect can be reduced to: 1. A Maintenance advice correctly maintains cache entries. 2. A Management advice always adds valid entries to the cache.  3. A Helper advice body is observationally equivalent to the joinpoint it advises. These three conditions can be checked via local reasoning on the developer side. Safe Cache-Based Optimization Aspects

50. Schema for Proof/Verification • Programmer obligations • follow the model • provide correct advice • management • maintenance • helper: replaces function call with a behaviorally equivalent advice body. • Guarantees of system • harmless • why it is harmful • maintenance advice missing • wrong advice configuration • double check the programmer obligations Safe Cache-Based Optimization Aspects