Better Blame Assignment for State and Behavioral Assertions Applied to Cache-Based Optimization Aspects Karl Lieberherr PhD work of Ahmed Abdelmeged Northeastern

Better Blame Assignment for State and Behavioral Assertions

Applied to Cache-Based Optimization Aspects

Karl LieberherrPhD work of Ahmed Abdelmeged

Northeastern University

6/16/2011 1Safe Cache-Based Optimization Aspects

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.


Pattern applies to many algorithms

• Topological ordering • Closest pair• Dijkstra’s shortest path• Union-find• Prim• Kruskal, etc.

6/16/2011 Safe Cache-Based Optimization Aspects 3

Topological Ordering

• Input: DAG G=(V,E)• Output: Topological Ordering of G• use several slides


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


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?


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



sourceNodes()


Graph


Node


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); } }


Asymptotic Improvement


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.








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.


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.



• 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.



• 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.



• 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


Contracts for Aspects: Monitoring

• State-Assertion violated• Most recent deterioration point for state-

assertion



• 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.


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

1. blame the stack trace at the join point failing a test.

2. at the most recent deterioration join point. That is the joinpoint before which the assertion succeeded and after which it failed.


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


Aspect Interactions

• Only blame aspect interactions that would have broken an aspect contract.








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


Reusable aspect contracts

• Cache-based optimization aspects– serve as basis for constructing a LDASL for this

family of aspects.


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.


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).








Design Structure MatrixProgram Opt Base

iMethods Rest

Opt XXX X no dependency

Base iMethods XXX

Rest XXX

Base: Program to be optimized. iMethods: methods with cache support Rest: rest of base programOpt: Optimization aspect


Model

• Cache declaration• Three kinds of advice

– maintenance• compensates for destructive updates

– management• storing certain subcomputations

– helper• make more amenable to cache-based optimization


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).


Motivation for Helper Advice

• Requires invention.• Use Dijkstra’s shortest path algorithm as

example.


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?



• 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.


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.


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


Pure Aspects

• An aspect is pure if– all advice are purse computations– around advice can only replace join points of pure

computations


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).


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.


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.


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).


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.


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:



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.


Model

• We model a cache-based optimization aspect as – a pointcut identifying the memoized method, – a number of

• maintenance, • management and • helper advice.


Local ReasoningBased 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.


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








Related Work

• Domain-Specific Aspects• Pure aspects, Elcin Recebli (Master

dissertation at Oxford, Wolfson College, advisor: Oege de Moor)– attachable aspects– pure aspects: We shall call an aspect whose only

possible visible effect is added new functionality, but not altered old one, pure.


Related Work

• JAMI: W. Havinga, L. Bergmans, and M. Aksit. Prototyping and Composing AspectLanguages using an Aspect Interpreter Framework . In ECOOP,pages 180--206, 2008.– uses maintenance advice– experimental DSAL


JAMI

cache Document object { memoize wordCount, invalidated by assigning content or calling addLine(java.lang.String);}


Conclusions

• Algorithm text books should use aspect-oriented pseudo code to optimize algorithms like: Topological ordering, Closest pair, Dijkstra’s shortest path, Union-Find, Prim, Kruskal, etc.– watch for function calls with identical or slightly

modified arguments– watch for helpers that facilitate caching– advantages: general technique broadly applicable


Conclusions

• Contracts for Aspects with good blame assignment seem to be useful.– Both advice configuration exploration and most

recent deterioration join points give good feedback to programmer.

• Remaining work: Replace some of the dynamic checking with static analysis.


Thank you!



Dijkstra’s Shortest Path Algorithm







• selectMin 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



• 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.


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.


Optimization Aspect








Entry


Cache


Ahmed 1. slide

• AOP: must reason globally about properties of base and aspects.

• Instead of reasoning globally, assert properties at run-time.

• When assertions fail, hard to assign blame to join points not on the call stack at the time of failure.


Ahmed slide 1: 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.



• 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.



• 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.



• Assertion violated– Try different configurations (helps with beh.

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)• hope to use static techniques


Contracts for Aspects: Monitoring

• state-Assertion violated• most recent deterioration point for state-

assertion


Lifting from Cache-Based Optimization to Contracts for

Aspects• What happens to modular reasoning?

– correctness proof argument

• ineffective aspect– if there are entries added that are never used– lookup can never succeeds

• cache maybe ineffective

• behavioral assertion – resource that is never used


Lifting from Cache-Based Optimization to 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.


Use cases for domain specific languages

• Contracts for Aspects– state assertions = data structure invariants

• cache consistency

– behavioral assertions• purity, before read

• Cache-based optimization aspects• ??• ??


Plan

• Start with concrete problem, then generalize.


Thesis

• Better Blame Assignment for State and Behavioral Assertions applied to Cache-Based Optimization Aspects


Problems of Cache-Based Optimization Aspects

• Make sure that cache is maintained correctly after an invalidation before it is read again.

• Use Design by Contract.• For state assertions blame the stack trace

1. at the join point failing a test.2. at the most recent deterioration join point. That

is the joinpoint before which the assertion succeeded and after which it failed.



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


Better Blame Assignment for Data Structure Invariants and Safety Conditions Applied to Cache-Based

Algorithm OptimizationKarl Lieberherr

PhD work of Ahmed Abdelmeged


From Cache-Based Algorithm Optimization to Better Blame Assignment for Data Structure

Invariants and SafetyKarl Lieberherr




• 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 beh. invariants violations.


• Contracts for Aspects•

• 1. Introduction:• Aspects interact with the rest of the program through implicit invocation and shared state. The rest of the program can drive the aspect into an invalid state either through a sequence of implicit advice invocations or

through mutation of the aspect's shared state. Take for example a caching aspect that stores a map from the input arguments of a particular method and the returned value. Destructive updates to the input arguments can invalidate the cache. To work properly, certain advice require the state of the aspect to be valid upon their execution. A memoization advice would be an example.

•

• When an advice is implicitly invoked on an aspect whose state is invalid, it is possible to blame the joinpoint(shadow) that implicitly invoked that advice as well as the joinpoint that invalidated the state of the aspect before that. But, in the presence of other aspects, certain aspect interactions can be blamed as well. For example, the joinpoint that invalidated the state of the aspect or invoked that advice could be a in the control flow of some executing advice. An around advice could as well be inhibiting the validity of the aspect state from being restored.

•

• There exist several systems for detecting aspect interactions ~\cite{martin's, refles, JAML, sudholt}. All these systems report aspect interaction warnings to the developers who are required to judge whether these interactions are problematic. We take this one step further by only blaming interactions that could have caused the breakage of an aspect contract. There are also systems that prevent certain classes of interactions such as state effects on the base program ~\cite{walker, PureAspects}. We also take this one step further by providing finer control over prevented interactions. Finally, in contrast to all these systems, our system checks contracts at runtime. It remains open how to statically check these contracts or subset thereof.

•

• 1.1. Contracts and Domain Specific Aspect Languages:• The typical goal of Domain Specific Programming Languages is to enable the development of a particular family of programs at a higher-level of abstraction than General Purpose Programming Languages. There are cases

were aspects written in AspectJ-like general purpose aspect-oriented programming languages do have a more pressing issue than being low-level. The issue is safety. In such cases, it is more important to develop Domain Specific Aspect Languages to enable safer development of a particular family of programs than it is to raise the level of abstraction.

•

• This can be achieved though developing a set of reusable aspect contracts for families of aspects. These reusable contracts can then be abstracted into the form of annotations or even generated from Domain Specific Aspect Languages. We call the first form Lightweight Domain Specific Aspect Languages (LDASL). LDASLs can be implemented using annotation processing tools and require minimal effort to learn. In this paper we develop a set of reusable aspect contracts for the family of cache-based optimization aspects that serve as a basis for constructing a LDASL for this family of aspects.

•

• 2. Cache-Based Optimization Aspects:•

• 3. Contracts for Aspects• Preconditions, postconditions and both invariants are attached to pointcuts. A precondition is checked before every joinpoint in its pointcut. A postcondition is checked after every joinpoint in its pointcut. An invariant

attached to pointcut p() is checked before and after every joinpoint in either cflow(p()) or !cflow(p()). We call the former an internal invariant and the later an external invariant. •


Algorithm Optimization:Trading Time for Space Using

Aspects==

Aspect ContractsKarl Lieberherr




• Need aspects for optimization. Need contracts for optimization aspects.

• Solve the more general problem: Contracts for Aspects.



Contracts for Aspectswith Applications to

Program OptimizationKarl Lieberherr





• Attached to pointcut p()– preconditions

• checked before every joinpoint

– postconditions• checked after every joinpoint

– invariants• before and after every joinpoint in

– cflow(p) // internal invariant– !cflow(p) // external invariant


Domain Specific Aspect Languages

• Our goal: safer development. When something is wrong with the aspect, blame will be assigned properly.

• Higher-level development? We know what kind of blame to avoid?

• Reusable aspect contracts. Expressed with annotations. Lightweight Domain Specific Aspect Languages (LDASL). – minimal effort to learn


Reusable aspect contracts

• Cache-based optimization aspects– serve as basis for constructing a LDASL for this

family of aspects.


Blame Assignment

• Advice is implicitly invoked on an aspect whose state is invalid– blame

• joinpoint (shadow) that implicitly invoked advice• joinpoint that invalidated the state of the aspect before

that• other culprits

– in control flow of some executing advice – around advice could be inhibiting validity of aspect state


Aspect Interactions

• Only blame aspect interactions that would have broken an aspect contract.

• Aspect contracts must have some notion of completeness?


Simulate Inheritance with Aspects

• Can we simulate subclassing with aspects and check whether we get the same blame assignment as in Meyer’s or Felleisen’s contract system for classes?


Problem

• Take your favorite Algorithms text book:• Typical pattern:





Pattern applies to many algorithms

• Topological ordering • Closest pair• Dijkstra’s shortest path• Union-find• Prim• Kruskal, etc.


Two Influences onCache-based Optimization Aspects• Domain Specific Aspect Languages (Crista Lopes)

– restrictions help• higher level of abstraction, separation of concerns• more safety

• Contracts for Aspects – dynamic checking of

• state assertions• behavioral assertions

– advice configuration checking– most recent deterioration join points


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.


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.


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




sourceNodes()


Graph


Node


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?


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); } }


Example: Dijkstra’s AlgorithmKleinberg/Tardos

• Algorithm: In 1959, Edsger Dijkstra proposed a very simple greedy algorithm …: – Dijkstra(G,l) = …– Running time O(mn)

• We can do considerably better if we use the right data structures:– O(m log(n))– find function for min that is more amenable to

cache-based optimization6/16/2011 119Safe Cache-Based Optimization Aspects

Design Structure MatrixProgram Opt Base

iMethods Rest

Opt XXX X no dependency

Base iMethods XXX

Rest XXX

Base: Program to be optimized. iMethods: methods with cache support Rest: rest of base programOpt: Optimization aspect


Model

• Cache declaration• Three kinds of advice

– maintenance• compensates for destructive updates

– management• storing certain subcomputations

– helper• make more amenable to cache-based optimization


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).


good

Model• Aspect

– field: cache– advice

• maintenance actuating …– augmenting (before/after) can have external side effects: change

values of cache entry but only values that are not reachable from outside the aspect.

– update entries• management (add entries) cannot change existing entries

– augmenting (before/after)– initialization or– maintenance under functional updates

• helper (replacing around advice, make more amenable to cache-based opt)


Pure Aspects

• Different concept from Recebli.• An aspect is pure iff

– it never • destructively updates any object reachable (has-a) from a

variable in the base program environment• throws an exception• performs IO

– around advice can only replace join points of pure computations

– What is a pure computation?• external side-effect free


Model

• What is the model definition?– Where is around advice allowed?– Is there also memoization advice in addition to

management, maintenance and helper advice?– Make model definition self contained: what is

memoization advice, what is a pure computation (no external side effects?).


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).


• Hi Ravi,• We have two questions regarding cache-based optimizations for algorithms (e.g. memoization). I've tried to put them in context below. Feedback appreciated.•

• Intro/Problem:• An optimized algorithm/program (OptAlgo) is often more complex than its unoptimized version (Algo). It is important to be able to prove/argue that OptAlgo is observationally equivalent to Algo and that OptAlgo outperforms Algo on some inputs. So that Algo can be used as a 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 as Java.•

• One other possibility is to write the pair as Opt+Algo where Algo is written in Java and Opt is an aspect is written in an aspect oriented programming language such as AspectJ. In this style, we need to prove/argue that Opt is harmless (i.e., Opt can never change the final value returned by Algo, if they terminate) 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.•

• 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:• 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.•

• Before proceeding to explain the model and what we mean by patterns 2,3.1,3.2. We have a question. Are these patterns exhaustive? Do you know of other cache-based optimization patterns?•

• Proposed Model:• • We model a cache-based optimization aspect as a pointcut identifying the memoized method, a number of maintenance, management and helper advice. In this model, it is possible to implement several cache-based optimizations such as memoization and memoization in the presence of destructive updates where maintenance advice compensate for the destructive updates. It is also possible to model application specific cache-based optimizations where the cache is used to reorganize the computation by precomputing and storing certain subcomputations through management advice. It is also possible to use helper advice to override the computation with an alternative computation that is more amenable to cache based optimization. Finally, when several cache-based optimization aspects are provided, an ordering aspect consisting of AspectJ-like declare precedence statements can be included.•

•

• The model imposes following restrictions that ease the task of proofing/arguing about its correctness• The memoized method must be pure (i.e., external side effect free).• A Helper is an around advice that:• 1) has a pure body.• 2) advising 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).• Once invalidated, cache entries must be maintained before being read. (i.e., there is no missing maintenance advice).•

• From the pointcut identifying the memoized method we generate a cache field as well as a memoization advice in the aspect:• The generated cache is guaranteed to be correct (i.e., if we put (a,v) in the cache then we get the value associated with a, we get back v). • The generated memoization method is also guaranteed to:• 1) Only destructively update the cache (to add new entries). • 2) Be observationally equivalent to the method it memoizes (m) as long as m is pure and the cache contents are kept valid.•

• Based on these restriction, 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.•

• In other words, the set of restrictions imposed by the model + the set of guarantees made by the translation to AspectJ + the set of conditions the developer is required to guarantee imply that the aspect is harmless. We generate monitor aspects that check that all these conditions are satisfied by the current program trace. These monitors provide a sort of hand-holding support for developers.•

•

• Patterns:•

• Pattern 2: Memoization + maintenance under destructive updates:• Consider the following method for computing the topological order of some graph:• public class Graph {• public List<Node> nodes = new ArrayList<Node>();• public Maybe<List<Node>> topologicalOrder(){• List<Node> orderedNodes = new ArrayList<Node>();• for(List<Node> sources = sourceNodes(); • sources.size() > 0 ; • sources = sourceNodes() ){• Node n = sources.get(0);• orderedNodes.add(n);• /*Destructive update*/ nodes.remove(n);• }• if(nodes.size() > 0 ) return new None<List<Node>>();• return new Some<List<Node>>(orderedNodes);• }• //rest is elided• }•

• We observe that the method sourceNodes() is invoked several times with the same implicit this argument. Suppose that we decided to memoize the method sourceNodes() (nodes with no predecessors). The statement nodes.remove(n) destructively updates the graph object sent as the implicit this parameter to sourceNodes. Effectively, invalidating the cache of source nodes. Luckily, it is possible to maintain the invalidated cache entries using a more efficient version of sourceNodes incrementalized/dynamized under nodes.remove(n). •

• In our model we can this cache-based optimization aspect as:• CacheDeclarationPointcut(Graph g): call(sourceNodes()) && target(g);• With a single maintenance advice:• after(Graph g, List l, Object removed): • cflow(call(* Graph.topologicalOrder())) • && cflow(call(* Graph.topologicalOrder()) && target(g)) • && call (* List+.remove(..)) && args(removed) && target(l)• && if(g.nodes == l){• for (Entry entry : cache.query(g)) {• Node removedNode = (Node) removed;• entry.value.remove(removedNode);• for (Node node : removedNode.getSuccessors()) {• if(entry.g.predecessorsOf(node).size() == 0){• if(!entry.value.contains(node)){• entry.value.add(node);• }• }• }• }• }• •

• Pattern 3.1: Memoization + maintenance under certain functional updates(to the keys of the cache)• consider the following example:• class ClosestPair {• static Result DCCP(List<Point> points){• int n = points.size();• if(n<=3){• return BFCP(points);• }else{• final Point xMedian = Utils.median(points, Point.xComparator);• List<List<Point>> s = Utils.partition(points, Point.xComparator, xMedian);• Result P1 = DCCP(s.get(0));• Result P2 = DCCP(s.get(1));•

• final Result cpInPartitions = P1.min(P2);• List<Point> ptsInStrip = Utils.filter(points, new Utils.Predicate<Point>(){• boolean holdsFor(Point point) {• return Math.abs(point.x - xMedian.x) > cpInPartitions.getDistance();• }});• Result cpInStrip = DCVSCP(ptsInStrip);• return cpInStrip.min(cpInPartitions);• }• }•

• static Result DCVSCP(List<Point> points){• /*Opportunity*/ List<Point> ySortedPoints = Utils.sort(points, Point.yComparator);• Result result = new Result();• for (int i=0;i<ySortedPoints.size();i++) {• Point pi = ySortedPoints.get(i);• for (int j=1;i+j<ySortedPoints.size()&&j<i+7;j++) {• result = result.min(new Result(pi, ySortedPoints.get(i+j)));• } • }• return result; • }•

• static Result BFCP(List<Point> points){• Result result = new Result();• for (int i=0;i<points.size();i++) {• Point pi = points.get(i);• for (int j=i+1;j<points.size();j++) {• result = result.min(new Result(pi, points.get(j))); • } • }• return result; • }• }•

• class Result {• private final double distance;• private final Point p1;• private final Point p2;•

• public Result(Point p1, Point p2){• this.distance = p1.distanceTo(p2);• this.p1 = p1;• this.p2 = p2;• }•

• public Result combine(Result other){• return (other.distance < distance)? other : this;• }• }• We observe that the method Utils.sort(..) is invoked several times with the same comparator argument and several related list arguments. The relation between these arguments can be described as:• 1. They might have common elements.• 2. There is a particular list from which all other lists are computed using the "functions" partition and filter.• If we choose to go with the second description, we can memoize sort. Use a management advice to add that particular list object to the cache and for each invocation of partition and filter, if the list it partitions/filters has a sorted counterpart, compute a sorted counter part for its returned list. This can be done using two management advice.•

•

• Pattern 3.2: Modification of the base program to make it more amenable to cache based optimization:•

• Example 1: Modify to make the program amenable to memoization under destructive updates: Suppose that we know that findmin(list) is invoked several times with one of the the minimum element in the list removed. Unfortunately, the old (removed) minimum can not be used to find the new list minimum. It is possible to use a helper advice to override findmin(list) with the more expensive heapify(list).findmin(). heapify(list) is amenable to incrementalization under removing the minimum. i.e., it is possible to use the heap computed for the old list to more efficiently compute a new heap for the same old list with the minimum element removed.• • Example 2: Modify to make the program more amenable to memoization: In the topological ordering example, we observe that predecessorsOf(..) is invoked several times with the same implicit list argument but with several "unrelated" node arguments. One optimization is to memoize predecessorsOf(..) and maintain the cache under the same destructive update from the earlier example. But, it is also possible to modify predecessorsOf(..) to reverse the given graph then retrieve the successors of the input not in the given graph. Again, the reverse graph needs to be maintained under the same destructive update from the earlier example. But, this way, we avoid doing a full graph traversal every time predecessorsOf(..) is invoked on some new node. Instead, a single graph traversal is used to compute the reversed graph and that computed reverse graph is used to speedup all subsequent predecessorsOf(..) invocations.•

•

•

• Finally, we want to push this further by enabling the developers to develop optimization aspects with only partial knowledge about the base program. This extends the possibility to prove/argue for the correctness of a cache based optimization aspect using only local reasoning. For that, we analyze a representative execution trace of the algorithm/program being analyzed to figure out the methods that are executed several times with the same set of arguments or with some of its arguments being the same. •

• In the former case, developers can rely on the extensive checks (mentioned earlier) to guide the rest of the development process. For example, developers can simply develop a memoization aspect and in case there were any statements that destructively update any of the arguments passed to the memoized method, the developers will be notified of these statements. In case the developer can not develop an efficient maintenance advice for a specific destructive update, they can use a helper advice to expose a particular subcomputation of the repeatedly called method that is more amenable to cache-based optimizations.•

• In the latter case, the developers have to figure out the relationships between the objects that can flow into the arguments that are not always the same. they also need to figure out if there was a particular subcomputation that is related only to the fixed set of arguments (such as the graph reversal case) and use a helper advice to expose such computations.•

• Our second question is: is this development process exhaustive enough? do you know of other cache-based optimizations to algorithms that could not be systematically derived using this process? •


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.


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 as Java.


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).


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.



• 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:



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.


Model

• We model a cache-based optimization aspect as – a pointcut identifying the memoized method, – a number of

• maintenance, • management and • helper advice.


Local ReasoningBased on these restriction, 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.


Properties and Checkability

• The set of restrictions imposed by the model + the set of conditions the developer is required to guarantee imply that the aspect is harmless.

• We generate monitor aspects that check that all these conditions are satisfied by the current program trace. These monitors provide a sort of hand-holding support for developers.


• Want to push this further by enabling the developers to develop optimization aspects with only partial knowledge about the base program. This extends the possibility to prove/argue for the correctness of a cache based optimization aspect using only local reasoning.

• We analyze a representative execution trace of the algorithm/program being analyzed to figure out the methods that are executed several times with the same set of arguments.


• developers can rely on the extensive checks (mentioned earlier) to guide the rest of the development process. For example, developers can simply develop a memoization aspect and in case there were any statements that destructively update any of the arguments passed to the memoized method, the developers will be notified of these statements.



Model Rules/contracts

• Restrictions on the behavior of individual advice as well as the behavior of the whole aspect.

• Individual– Control effect (Augmentation/ Narrowing /

Replacement / Combination)– Legal external effects

• As a whole– Safety (Cache must be maintained before it is read.)


Harmless / Correct

• Optimization aspect should only speed up the base program– observable qualities of program that you want to

preserve: return value– schema for proof


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

– harmless– why it is harmful

• maintenance advice missing• double check the programmer obligations


Asymptotic Improvement


aspect contracts

• write them once for a family of aspects


new


Problem

• Take your favorite Algorithms text book:• Typical pattern:





Use of caches• E.g., memoization: avoid running the same

computation more than once: time-memory tradeoff. Can be fully automated [Ding/Zi].

• 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.


Optimization: crosscutting


• Hi Karl, Let me rephrase that a bit. • • What is interesting is that we can reason modularly about the correctness of cache-based optimization, that we can get hints about the chances of ineffectiveness, and that we can express cache-based optimization aspects more concisely. (these are mentioned in the first half of my message to Ravi).• • What could be interesting (i.e. F.W.) is that• 1. We can develop optimization aspects based on PARTIAL knowledge of the base program.• 2. We can derive ordering aspects and prove its correctness.• 3. We can enhance the quality of purity and safety monitors.• 4. We develop the effectiveness "monitor".• 5. We can argue that our model is complete.• 6. We illustrate the performance of our approach practically.• 7. We develop static checkers for aspect purity, safety and effectiveness.•

On Wed, Jun 8, 2011 at 10:29 AM, Karl Lieberherr <[email protected]> wrote:Hi Ahmed:

What is really interesting is that you cananalyze a running program dynamically,get hints about a cache-based optimization aspect,and implement it based on PARTIAL knowledgeof the base program.

You also said that the technique can be iterated.Please can you elaborate on that in case ofDijkstra's algorithm.

• I'm working on that as it will be a part of Ravi's message (as well as the paper).• • In the XPI community they use design structure matrices

to show dependencies. Do DSMs help to visualize youroptimization aspects?

• Are you trying to say that DSMs can be used to illustrate aspect interactions? • When is your PL Junior Seminar presentation?

• Not scheduled yet. •

Your current abstract is not saying1. That you have a tool to detect optimization opportunities. (Does this tool give lots of false positives?)2. [Oblivious Optimization] That writing the optimization aspect requires only partial knowledge about the base, pointed to by tool 1.3. that when the programmer does its homework you can guranteecertain properties.

• The abstract is not saying these because these are future work.• • Let's Skype at 4pm?

-- Karl

• OK, attached is the current version. I've changed the list in which application specific optimizations are more liberal. I've also changed the model and the modular reasoning about correctness part to improve the flow. Will send you the next version later this afternoon.


mailto:[email protected]

Related Work

• Design by Contract and Aspect-Oriented Development, CSE 294 Seminar, contains good references.– contracts governing the semantics of aspects– Date?


Related

• Contracts for Aspect-Oriented Design (Ana Moreira et al.) after 2007

• @inproceedings{Agostinho:2008:CAD:1408647.1408648, author = {Agostinho, S\'{e}rgio and Moreira, Ana and Guerreiro, Pedro}, title = {Contracts for aspect-oriented design}, booktitle = {Proceedings of the 2008 AOSD workshop on Software engineering properties of languages and aspect technologies}, series = {SPLAT '08}, year = {2008}, isbn = {978-1-60558-144-6}, location = {Brussels, Belgium}, pages = {1:1--1:6}, articleno = {1}, numpages = {6}, url = {http://doi.acm.org/10.1145/1408647.1408648}, doi = {http://doi.acm.org/10.1145/1408647.1408648}, acmid = {1408648}, publisher = {ACM}, address = {New York, NY, USA}, keywords = {aspect-oriented design, aspect-oriented programming, design by contract, object-oriented design, object-oriented programming}, }


Documents

Better Blame Assignment for State and Behavioral Assertions Applied to Cache-Based Optimization Aspects Karl Lieberherr PhD work of Ahmed Abdelmeged Northeastern