A Reversible Abstract Machine and its Space Overhead

A Reversible Abstract Machine and its Space Overhead Ivan Lanese Focus research group Computer Science Department University of Bologna/INRIA Italy Joint work with Michael Lienhardt, Claudio Mezzina and Jean-Bernard Stefani 1

Roadmap l Reversibility and concurrency l μOz l Reversing μOz l Space overhead l Conclusions

Why reversibility? l l We want programming abstractions for dependable distributed systems Different proposals in the literature – Exception handling, checkpointing, transactions, … l Unrelated proposals, difficult to combine and compose Is there a unifying concept? l … most of them include some form of undo l

What if we could undo every action? l l Very low-level mechanism Can we build suitable abstractions on top of it? Can we recover and better understand traditional recovery schemes? Can we find new schemes or combine old ones?

Reversing concurrent systems l What does it mean to go back one step for a concurrent system? Which information is needed? l First approach in l Reversible Communicating Systems. CONCUR 2004 by V. Danos and J. Krivine

Reversible Communicating Systems l Presents the RCCS calculus – A reversible version of CCS l l History information is added to each thread Causal consistent reversibility – Transitions should be rollbacked in any order compatible with causal dependencies

Causal consistent reversibility a b b a

Causal consistency theorem l Computations coinitial and cofinal should be equivalent up to – Simplification of a step and of its undo – Swap of concurrent actions l Intuition: – We have to rollback non equivalent computations differently – We need them to lead to different states, otherwise we don’t from where we come from

From RCCS to Rhopi l In CONCUR 2010 we defined Rhopi – A causal consistent reversible higher-order pi – Shows how to reverse calculi with (higher-order) message passing l l l When developing rhopi we did not consider efficiency issues We want to consider it now Is history information stored in Rhopi in an efficient way? – Intuitively not – Duplication of communicated messages and continuations

Giving a formal answer to the question l l Rhopi space consumption should be compared to HOpi one HOpi is at a very high-level of abstraction – Difficult to understand the actual amount of memory used by an HOpi process – HOpi may not be space efficient on its own l We would need an abstract machine for HOpi – Providing an efficient implementation – Accepted by the community l No such abstract machine exists for HOpi – Actually no abstract machine at all

A path towards the solution l l We move from HOpi to μOz is an higher-order language – Thread-based concurrency – Asynchronous communication via ports l μOz advantages: – Similar to HOpi – Has a well-known and rather classical stack based abstract machine » Suitable as a reference implementation l l We do the space complexity analysis in μOz setting Can we reverse μOz efficiently?

A side effect l μOz is nearer to real languages – Stores and variables – Sequence, if-then-else and procedure calls l l We test the techniques developed for HOpi in a more realistic scenario Further steps needed to tackle real languages

Roadmap l Reversibility and concurrency l μOz l Reversing μOz l Space overhead l Conclusions

μOz syntax S : : = j j j j j Statements skip Empty statement S 1 S 2 Sequential composition let x = v in S end Variable declaration if x then S 1 else S 2 end Conditional statements thread S end Thread creation flet x = c in Sg end Procedure declaration x x 1 : : : xn Procedure call in S end flet x = New. Port g Port creation Send xf y g Send on a port let x =j Receive y in S end Receive from a port v : : = true f false g Simple values c : : = proc x 1 : : : xn S end Procedure

μOz semantics l l Programs written as stacks of instructions A rule transforms a pair (program, state) into a new pair Variables are always created fresh and never modified We always send names of variables, not their content – Global store

μOz sample rules h i let x = v in S end T x'=v 0 hf h f 0 g i S x =x T g Send x y T k x=» » : Q i T k x=» » : y; Q h f g i let x = Receive y in S end T k k y=» » : Q; z z = w h f 0 g i S x =x T k k k 0 y=» » : Q z = w x = w

Roadmap l Reversibility and concurrency l μOz l Reversing μOz l Space overhead l Conclusions

Making μOz reversible l We add history information to each thread – Keeping trace of actions executed in the past l l We add unique names to threads For most statements, we add a delimiter esc to define their scope – E. g. , for let, if-then-else and procedure call l l We add history information also to queues We add a symmetric version for each rule

Making let rule reversible h i let x = v in S end T 0 h f 0 g i S x =x T x'=v

Making let rule reversible h i t[H] let x = v in S end T 0 h f 0 g i S x =x T x'=v Unique thread id and past history

Making let rule reversible h i t[H] let x = v in S end T 0 h f 0 g h ii t[H *x'] S x =x T x'=v History now includes the new action

Making let rule reversible h i t[H] let x = v in S end T 0 h f 0 gh ii esc sc T t[H *x'] S x =x e x'=v Scope delimiter

Making let rule reversible h i t[H] let x = v in S end T h f 0 gh ii esc sc T t[H *x'] S x =x e x'=v 0 l Adding the inverse rule: h h ii t[H *x] S esc T x=v h i t[H] let x = v in S end T 0

Reversible sample rules hf t[H] g Send x y T k x=» » : Q hf i g Send x y T k j x=» » : Q Qh " T k x=» » : y; Q i t[H x]T k j x=» » : t : y; Q Qh t[H " x=» t[H] hf k x]T j » : t : y; Q Qh g Send x y T k j x=» » : Q Qh i

μOz sample rules h f g i let x = Receive y in S end T k k y=» » : Q; z z = w h f g i t[H] let y = Receive x in S end T k k j 0 x=» z = w » : Q; t : z Qh # h h ii t[H x(z)] S esc T k k j 0 z=w x = » » : Q t : y; t; Qh h f 0 g i S x =x T k k k 0 y=» » : Q z = w x = w # h f 0 gh ii t[H x(y )] S y =y esc T k k j 0 k 0 x=» z = w » : Q t : z; t; Qh y = w 0 h f g i t[H] let z = Receive x in S end T k j 0 x=» » : Q; t : y Qh

Basic properties l l Preservation of μOz semantics Loop Lemma – Every step can be perfectly undone l Causal consistent reversibility – Coinitial traces are cofinal iff they are causally equivalent

Roadmap l Reversibility and concurrency l μOz l Reversing μOz l Space overhead l Conclusions

Space complexity l We compute the space overhead of the reversible abstract machine w. r. t. the original one – Size of a reversible configuration minus size of the corresponding μOz one l For a fixed program, the overhead is linear in the number of computation steps – Clear by looking at the size of the stored history information – Only non constant information for discarded branch of if-thenelse and number of parameters of procedure calls

Optimality of linear memory overhead l l l Is the space overhead optimal (in order of magnitude)? We prove a linear lower bound by giving a program that requires at least a linear overhead Program composed by 3 threads communicating via a shared queue – T 1 sends value true, T 2 sends value false – T 3 receives the values in fresh variables

The counterexample

Assumptions l l We consider computations where we do all the sends first, then all the receives When all the messages have been received – We can count the number of true and of false – But we cannot recover the order in which they have been sent l We divide the sends in pair, and we require that in each pair a send is from T 1 and one from T 2 – Same number of true and false – Two possibilities for each pair

The counterexample Two possibilities for each pair

The counterexample After all the reads the computations are indistingushable

Proof strategy l l All the computations are coinitial and cofinal but not causally equivalent We need to distinguish them – We need one bit for each pair – All the possibilities, thus also incompressible strings l l The number of bits is linear in the number of steps We require a linear amount of memory

Discussion l l l Overhead due to nondeterminism in communications A similar example can be defined for nondeterminism in thread scheduling Deterministic computations actually would need less space – Just the number of performed steps, which takes logerithmic space – Tradeof between space and time efficiency

Roadmap l Reversibility and concurrency l μOz l Reversing μOz l Space overhead l Conclusions

Summary l l l A reversible abstract machine for μOz Linear overhead with respect to the standard machine A linear lower bound for the overhead – Due to nondeterminism

Future work l Proceeding towards real languages – Modules, types, exceptions, … – Concurrent ML? l l Analyze space efficiency for controlled reversibility Analyze different tradeofs between space and time overhead

Finally