A Core Calculus for Static Latency Tracking with Placement Types
aa r X i v : . [ c s . P L ] J u l A Core Calculus for Static Latency Trackingwith Placement Types
Student Research Competition @ POPL 2019
Tobias Reinhard
Technische Universität DarmstadtGraduate Student
ABSTRACT
Developing efficient geo-distributed applications is challenging asprogrammers can easily introduce computations that entail high la-tency communication. We propose a language design which makeslatency explicit and extracts type-level bounds for a computation’sruntime latency. We present our initial steps with a core calculusthat enables extracting provably correct latency bounds and out-line future work.
Developing efficient geo-distributed applications remains a chal-lenging task. Efficiency is largely determined by latency causedby remote communication. Avoiding high-latency remote commu-nication and exploiting locality is therefore imperative [15]. Dis-tributed components are, however, often interconnected and localcomputations can trigger a chain of events causing high-latencyremote computations [10, 11, 13]. Determining which local compu-tations eventually lead to latency, introducing remote communica-tion, often requires a global view which hinders modular develop-ment of geo-distributed software. Also, the exact location wherea remote computation is placed, matters. Communication amongservers in a single data center, for instance, is much faster (under2ms) than communication between geo-distributed data centrespossibly located on different continents (over 100ms) [3].We build on the idea of making locations and latency explicit [14]and adopt the approach that a computation’s location and its en-tailed latency become part of its type. The type system can inferan upper bound on a computation’s actual latency and can rejectcode containing wrong assumptions, e.g., on the latency caused bya method invocation. As a method signature already describes thelatency its invocation entails, no global view is required anymoreand code becomes more modular.In this work, we present our work on formalizing the type sys-tem in a core calculus λ lat , on extracting latency bounds, and onproving their correctness. We outline ongoing work about furtherextending the formalization and about enabling latency-saving refac-torings. Finally, we discuss how we plan to evaluate this researchline. Supervisors : Guido Salvaneschi (Technische Universität Darmstadt),Pascal Weisenburger (Technische Universität Darmstadt).
In the following we present λ lat as well as the ideas behind its cor-rectness proof. The goal of λ lat is to track the location (called a Author’s address: Tobias Reinhard, Technische Universität Darmstadt. peer ), on which a computation is run, and the latency it causes inthe type system. In this calculus, a computation’s latency refersto the weighted number of remote messages sent during the com-putation. The time a message needs to reach its recipient dependson the involved peers. For a fixed set of peers, e.g., found in geo-distributed data centers, we can assume fixed locations, and thus,known latency values, e.g., known from monitoring. We thereforeuse a function L : P × P → N to assign weights (i.e., latency ap-proximation) L( P , P ′ ) to the messages sent from peer P to P ′ . Dynamic Semantics. λ lat is an extension of the typed lambda cal-culus [2] where every computation is placed on a specified location.Peer types P and peer instances p specify type-level and runtimelocations, respectively. Types are augmented by sizes and latencybounds. We use a fragment of Heyting arithmetic [9] containing 0, S , +, Û− and · to define those and prove arithmetic properties.The small step reduction relation I { describes a reduction stepon a set of peer instances I . Locations and latency are explicitin the reduction semantics. Every intermediate result as well asthe end result of a term’s reduction is annotated by its locationand the latency its reduction has caused. A peer evaluation con-text (h t i I , [ l ]) describes a term t to be evaluated on a set of peerinstances I where l is the latency that has been caused duringthe reduction so far. A reduction step (h t i I , [ l ]) I { (h t ′ i I , [ l ′ ]) ex-presses that term t is reduced on the peer instances I to t ′ and thatthe tracked latency increases from l to l ′ . Local reduction stepsare standard and leave the tracked latency unchanged. Also, nolatency-decreasing steps exist. Hence, we have l ≤ l ′ . However,every reduction step involving a message sent from a peer P to P ′ increases the tracked runtime latency by the weight L( P , P ′ ) Consider the evaluation of the term get p ′ . v on a set I P of P -instances. The expression requests a value v from p ′ and can bereduced by sending the request to p ′ , increasing the latency by L( P , P ′ ) . Hence, the reduction step is (h get p ′ . v i I P , [ l ]) I P { (h(h v i { p ′ } , [ ])i I P , [ l + L( P , P ′ )]) . A remote evaluation (h v i { p ′ } , [ ]) starts with a remote latency of 0.When the result is transmitted, the remote latency is added to thelocal latency. Since we assume v to be a value, it cannot be reducedany further and the next step is sending v from p ′ to I P . Runtimelatency thereby increases to l + L( P , P ′ ) + L( P ′ , P ) . Static Semantics.
Assigning types to well-formed terms t ensuresthat there is a sequence of reduction steps towards a value (h v i I , [ l ]) and that v belongs to that type. Our approach lifts the latency of ev-ery reduction step to the type level. Additionally we ensure termi-nation of recursive functions by employing sized types [1] and onlyallowing size-decreasing recursion. A type is a triple ( B , [ s ] , [ l ]) . B obias Reinhard is a basic type like Unit determining the kind of value a term re-duces to, s and l are arithmetic terms representing the value’s sizeand an upper bound on the latency caused during reduction. [ s ] and [ l ] denote the equivalence classes of terms provably equal to s and l , respectively, in Heyting arithmetic. Type-level Latency.
Considering the term get p ′ . t (similiar to theexample above but without assuming p ′ and t to be values) and ab-stracting over concrete peer instances: Evaluating this term means(i) evaluating p ′ on the current peer P , (ii) sending a request for t to the remote peer P ′ , (iii) waiting for its evaluation and (iv) P ′ sending the result to P . We lift the runtime latency l p ′ + L( P , P ′ ) + l t + L( P ′ , P ) to the type level, as typing rule T-Get shows: P ↔ P ′ ∆ ; Γ ; Λ ; P ⊢ p ′ : ( P ′ , [ ] , [ l p ′ ]) ∆ ; ∅ ; ∅ ; P ′ ⊢ t : ( B , [ s ] , [ l t ]) ∆ ; Γ ; Λ ; P ⊢ get p ′ . t : ( Option ( B , [ s ]) , [ ] , [ l p ′ + L( P , P ′ ) + l t + L( P ′ , P )]) (T -Get ) Latency Bounds.
Analyzing a term’s structure is not always suf-ficient to compute its exact runtime latency. In general, terms canhave multiple reduction sequences resulting in different runtimelatencies. We therefore consider type-level latency as an upperbound on all possible runtime latencies, the typed term can reduceto. For instance, considering the term if t c { t t } { t f } : In any case,the condition t c is evaluated and depending on the result also oneof the branches t t and t f . As shown by rule T-If, we extract anupper bound by taking the maximum over both branches’ latency: ∆ ; Γ ; Λ ; P ⊢ t c : ( Boolean , [ ] , [ l c ]) ∆ ; Γ ; Λ ; P ⊢ t t : ( B , [ s ] , [ l t ]) ∆ ; Γ ; Λ ; P ⊢ t f : ( B , [ s ] , [ l f ]) ∆ ; Γ ; Λ ; P ⊢ if t c { t t } { t f } : ( B , [ s ] , [ l c + max ( l t , l f )]) ( T-If ) Size-dependent Functions.
In the case of functions, the latencycan depend on the input’s size. Considering a list processing func-tion f , where the processing of each element involves some latency l : For any list a of size s a the latency of an application f a is s a · l . In λ lat , such a function’s basic type has the form ∀ ( s : N ) . ( B , [ s ]) →( B ′ , [ s ′ ] , [ l ′ ]) . It expresses that the function can handle argumentsof type B and arbitrary size s and that every such argument ismapped to a value of type ( B ′ , [ s ′ ] , [ l ′ ]) where variable s may occurfree in s ′ , l ′ . For instance, in the previous example, we get l ′ = s · l . Size-decreasing recursion.
Recursion is a convenient way to de-fine size-dependent functions. In λ lat , the only way to express re-cursion is via a fixpoint operator. Our type system ensures thatfor every application to an argument of size s , the recursive step istaken on a smaller argument of size s ′ < s . Since sizes are finite, ourtype system ensures termination. Thus, application of the fixpointoperator preserves the correctness of extracted latency bounds. Correctness.
We have shown how our type system lifts runtimelatency to the type level and extracts upper bounds for branchingterms. We also showed how we can extract latency bounds for re-cursive function applications. Hence, we can prove the following:
Theorem 1 (Correctness of Type-level Latency Bounds).
Let ∆ and Γ be typing environments for placed and local variables, re-spectively. Let Λ be a set of arithmetic assumptions and P a peer type, I a set of peer instances, t a term, v a value. Further, let B be a basictype, s a size and l R , l T latencies. Suppose ∆ ; Γ ; Λ ; P ⊢ t : ( B , [ s ] , [ l T ]) and that there exists a reduction sequence for t to a value (h v i I , [ l R ]) .Then l R ≤ l T holds. We are currently investigating whether the extracted type-levelbounds are optimal regarding the worst-case runtime latency. Thisis particularly interesting for recursive functions where we needto check that an input exists that (i) causes the estimated maxi-mal number of recursive steps and (ii) in each step meets the ex-tracted latency bound. As message delay in distributed systems isnon-deterministic, we plan to refine our approach by using proba-bility distributions for the latency weights L( P , P ′ ) instead of nat-ural numbers.An important aspect to consider is to complement the (static)analysis provided by the type system with actual latency measure-ments collected via monitoring. We believe that the combinationof both can provide correct feedback to the developers. To this end,we are working on a monitoring system that provides realistic es-timations for latency and retrofits them in the type system usingmethods from continuous integration.We are currently implementing a prototype of the language pre-sented in [14] based on the type system of λ lat . Eventually, we aregoing to implement type-based latency tracking in ScalaLoci [12],a multitier language whose type system keeps track of a computa-tion’s location similar to λ lat .Using ScalaLoci’s extended type system, we are going to ex-plore latency-saving refactorings. High-latency inducing computa-tions often contain unnecessary remote communication. Relocat-ing parts of the computation and only transmitting as few data asnecessary helps to reduce latency. We believe that the combinationof static location and latency information is sufficient to implementsuch refactorings.We plan to evaluate the type system’s usability with controlledexperiments and case studies on applications involving multiplegeo-distributed data centres. Using platforms like Amazon AWS,we plan to use real locations for the data centers [6] and to specifyrealistic latency weights L( P , P ′ ) for the connections. This paper builds on our previous work presenting the design of alanguage which makes latency transparent to the programmer [14].To the best of our knowledge, no previous work formally explorestype-level latency tracking to promote low-latency computations.Jost et al. [8] augment a type system with cost values to extractupper bounds on the worst-case execution time and heap spaceusage. Their approach, however, targets embedded systems whereboth time and space bounds are important.Delange and Feiler [5] propose an incremental, model-based ap-proach to analyse the validity of latency requirements in cyber-physical systems.Cohen et al. [4] present a type system raising the developer’sawareness for inefficient code in terms of energy consumption.Their approach augments types by energy consumption patternsand uses type inference to track a program’s energy consumption.Session types (e.g., Hu et al. [7]) have been successfully appliedto distributed programming to check distributed protocols, but fo-cus on protocol correctness rather than communication cost. Core Calculus for Static Latency Trackingwith Placement Types
REFERENCES [1] Andreas Abel. 2007. Type-based termination: a polymorphic lambda-calculuswith sized higher-order types.[2] Henk Barendregt, J Barwise, D Kaplan, HJ Keisler, P Suppes, and AS Troelstra.1984. Studies in Logic and the Foundations of Mathematics.[3] Philip A. Bernstein, Sebastian Burckhardt, Sergey Bykov, Natacha Crooks,Jose M. Faleiro, Gabriel Kliot, Alok Kumbhare, Muntasir Raihan Rahman, VivekShah, Adriana Szekeres, and Jorgen Thelin. 2017. Geo-distribution of Actor-based Services. In
Proceedings of PACMPL (OOPSLA ’17) . ACM, New York, NY,USA.[4] Michael Cohen, Haitao Steve Zhu, Emgin Ezgi Senem, and Yu David Liu. 2012.Energy Types. In
Proceedings of OOPSLA ’12 . ACM, New York, NY, USA.[5] Julien Delange and Peter H. Feiler. 2014. Incremental latency analysis of hetero-geneous cyber-physical systems. In
Proceedings of REACTION ’14
Proceedings of the 22Nd European Conference onObject-Oriented Programming (Paphos, Cypress) (ECOOP ’08) . Springer-Verlag,Berlin, Heidelberg, 516–541. https://doi.org/10.1007/978-3-540-70592-5_22[8] Steffen Jost, Hans-Wolfgang Loidl, Norman Scaife, Kevin Hammond, GregMichaelson, and Martin Hofmann. 2009. Worst-case execution time analysis through types. In
Proceedings of ECRTS ’09 .[9] Ulrich Kohlenbach. 2008. Applied Proof Theory - Proof Interpretations and theirUse in Mathematics. In
Springer Monographs in Mathematics .[10] Manisha Luthra, Boris Koldehofe, Pascal Weisenburger, Guido Salvaneschi, andRaheel Arif. 2018. TCEP: Adapting to Dynamic User Environments by EnablingTransitions Between Operator Placement Mechanisms. In
Proceedings of DEBS’18 (Hamilton, New Zealand). ACM, New York, NY, USA.[11] A. Margara and G. Salvaneschi. 2018. On the Semantics of Distributed ReactiveProgramming: the Cost of Consistency.
IEEE Transactions on Software Engineer-ing (2018).[12] Pascal Weisenburger, Mirko Köhler, and Guido Salvaneschi. 2018. DistributedSystem Development with ScalaLoci.
Proc. ACM Program. Lang.
2, OOPSLA,Article 129 (Oct. 2018), 30 pages. https://doi.org/10.1145/3276499[13] Pascal Weisenburger, Manisha Luthra, Boris Koldehofe, and Guido Salvaneschi.2017. Quality-aware Runtime Adaptation in Complex Event Processing. In
Pro-ceedings of SEAMS ’17 . IEEE Press, Piscataway, NJ, USA.[14] Pascal Weisenburger, Tobias Reinhard, and Guido Salvaneschi. 2018. Static La-tency Tracking with Placement Types FTfJP. In
Proceedings of the 20th Workshopon Formal Techniques for Java-like Programs (FTfJP’20) .[15] Mike P. Wittie, Veljko Pejovic, Lara Deek, Kevin C. Almeroth, and Ben Y. Zhao.2010. Exploiting Locality of Interest in Online Social Networks. In