Translation and Optimization for a Core Calculus with Exceptions

1. Translation and Optimization for a Core Calculus with Exceptions Cristina DavidCristian Gherghina Wei-Ngan Chin National University of Singapore PEPM 2009

2. Motivation • Source languages are expected to be rich in features. • Drawbacks: • often too complex to analyse • exceptions are often omitted during formulation of program analysis PEPM 2009

3. Our proposal • An unified view of the control flow: • Unify both normal and abnormal control flows • provide unified language constructs that work for all kinds of control flow • Unify both static and dynamic control flows • static flow: break, continue, return • dynamic flow: try-catch, raise PEPM 2009

4. Contributions of Core Calculus • As small as a corresponding one without exceptions. • Supports the translation of challenging constructs from the source language. • Easier to analyse than the source language. PEPM 2009

5. Unified control flow hierarchy can be caught dynamic control flows due to exceptions static control flows cannot be caught normal execution PEPM 2009

6. Key principles of Core Calculus • Unified constructs • unify together constructs with similar functionality • Syntactically minimal • fewer and simpler constructs • Expressively maximal • language constructs as general as possible • Computationally positive • does not hinder efficient computation PEPM 2009

7. Outline • Motivation and contributions • Translation • Optimization • Conclusions PEPM 2009

8. Source language SrcLang • Supports constructs challenging from the point of how control flow is transferred: • finally construct • multi-return function call • try catch with multiple handlers • abnormal controls due to breaks and continues for loops PEPM 2009

9. The core language Core-U flow and value assignment catch handler flow + embedded type PEPM 2009

10. Important constructs of Core Calculus • Flow and value: ft#v • normal flow: norm#v • exceptional flow: ty(v)#v • Try-catch construct: try e1 catch((c@fv)#v) e2 • captures both exceptional and normal control flow control flow the thrown value variable capturing the control flow type (fv<:c) PEPM 2009

11. Uniform translation • Uniformly manipulate some of the source language constructs PEPM 2009

12. The finally construct • Any control flow that escapes e1 and can be caught • ( <:c-flow), will lead to the execution of the finally block. PEPM 2009

13. Multi-return function call [Shivers&Fisher, ICFP’04] • Evaluate the inner application: • if it returns val to vk.ek : • vk is bound to val • ek is evaluated in the caller’s context • the return construct, ret−i e : • the result of evaluating e is returned to the i-th ret point of the caller PEPM 2009

14. Example string a obj int n … mn (…) { e = (f 6) ( x.x) ( y.length(y)) ( z.ret-1 z) mn ( x.x) length(a) n } obj PEPM 2009

15. A more involved example filter :: (A->Bool) -> [A] -> {ret-2:(),ret-1:[A]} filter f lis =   case lis of    Nil  -> ret-2 ()    x::xs -> if (f x) then x :: ((filter f xs) (x.x) (_.ret-2 ()))     else (filter f xs) (x.x) ( _ .ret-1 xs)  end mft :: (A->Bool) -> [A] -> [A] mft f lis = filter f lis (x.x) (_. lis) PEPM 2009

16. Multi-return function call • Explicitly captures the choice of the return point, based on the • control flow caught after the evaluation PEPM 2009

17. Other translation rules • try catch with multiple handlers • abnormal controls due to breaks and continues for loops • local binding PEPM 2009

18. Completeness and termination of the translation • Completeness: Consider any term e ∈ SrcLang. Repeated applications of the transformation rules will result in e’ ∈ Core−U, when the transformation terminates. • Termination: The transformation always terminates. PEPM 2009

19. Big-step semantics • Provided operational semantics rules. • Used them for proving the correctness of subsequent optimization rules. • Details in the paper! PEPM 2009

20. Outline • Motivation and contributions • Translation • Optimization • Conclusions PEPM 2009

21. Re-ordering rule • Group together a nested series of expressions with a similar property. (e1;e2);e3 e1;(e2;e3) PEPM 2009

22. Catch elimination rule • Ensures the elimination of redundant catch handlers. determines if c shares some common subtypes with c1 captures all the flows that escape e PEPM 2009

23. A study of exception handling and its dynamic optimization in Java [Ogasawara,Komatsu,Nakatani,OOPSLA01] • Linking: an exception always caught by a handler (in the same method) is replaced with an explicit control flow to the catch. • Inlining: applied to non-recursive methods to link exception throwing points with its catch handler in a parent method. • Improves performance of exception-intensive programs by up to 18.3% • No correctness proofs. • Our optimizations: • were proven correct. • it is possible to perform inter-procedural optimization, through methods with multiple returns. PEPM 2009

24. Jump to the handler • Optimize stack unwinding when propagating an exc to its handler. • A raised exc caught by the same handler is replaced by a jump to its handler’s code. • Need to pass the control flow & its thrown value to the handler during the jump. PEPM 2009

25. Parameterized jump • jump(L(v*)) : carries a list of arguments for its labeled location. • L(v* : e) : vars v* in e can be initialized by the corresponding jump. • We model the jump with an abnormal control flow to be caught by its labeled handler: • jump−L#(ft, x) • each flow type jump−L will only be captured by its handler at the labeled location L. PEPM 2009

26. Throw-catch linking rule an expression with a single hole type environment determines if fc escapes its given context C[] PEPM 2009

27. Jump inlining rule • After some throw-catch linkings, we might have a series of consecutive jumps. inline the jump control flows from e are never caught by C[] or by the outer try-catch PEPM 2009

28. Implementation • Verified the absence of bugs in a few exception handling programs. • Performed the normalization. • linear increase in the size of the programs. PEPM 2009

29. Conclusions • An unified view of the control flows: • unifies both normal and exceptional executions. • Translation rules for challenging language constructs. • Optimization rules for reducing the implementation overhead. PEPM 2009

30. Thank you! Questions? PEPM 2009

31. Try-catch with multiple handlers • Every flow will skip the outer handlers, and will only be caught by the outermost handler. try ei catch((c-flow@fv)#v) spec#(fv,v) PEPM 2009