Reversible Garbage Collection for Reversible Functional Languages

Abstract

Reversible functional languages have been proposed that use patterns symmetrically for matching and building data: A pattern used on the left-hand side of a function rule takes apart a data structure, and a pattern used on the right-hand side of a rule builds a data structure. When calling a function in reverse, the meaning of patterns are reversed, so patterns on the right-hand side take apart data and patterns on the left-hand side build data. If using a pattern to build data creates a node with exactly one reference, a node that is taken apart must by symmetry also have exactly one reference. This implies linearity: A node that is built or taken apart has exactly one incoming reference. A recursive function can take apart one data structure while building two or more new copies, allowing multiple uses of values, but the new copies will also have one reference each. Linearity makes garbage collection simple: Whenever a node is taken apart by pattern matching, it is freed. The cost is that multiple uses of a value require deep copies. The reason for the linearity restriction is the symmetry between constructing and deconstructing nodes: Since constructing a node creates exactly one reference to this node, the inverse can only be applied if the reference count is exactly one. We can overcome this limitation if constructing a node can return a node with multiple references. We achieve this through maximal sharing: If a newly constructed node is identical to an already existing node, we return a pointer to the existing node (increasing its reference count) instead of allocating a new node with reference count one. This allows multiple references to nodes while retaining the symmetry of pattern matching and construction, and it allows values to be used multiple times without making deep copies. To avoid searching the entire heap for an identical node, we use hash-consing to restrict the search to a small segment of the heap. We estimate how large this segment needs to be to give a low probability of allocation failure with acceptable utilisation and support this estimate with experiments. We sketch how a functional program can be translated to use the memory manager, and we test the memory manager both with artificial test programs and a hand-compiled functional program.

Appendices

Appendix: Formal Semantics of RIL

Figure 9 shows a formal semantics for execution of RIL as rules for state transitions. A state consists of the program P (which never changes), an environment $\rho$, that maps named variables to integers, a memory store $\sigma$, that maps word-aligned addresses to integers, a stack S that stores return labels, and the current label l. A transition of the form $P~\rho ~\sigma ~S~l \rightleftharpoons P~\rho '~\sigma '~S~l'$ states that a state $P~\rho ~\sigma ~S~l$ will lead to the state $P~\rho '~\sigma '~S~l'$ in one or more steps.

The semantics shows how execution of a basic block makes a transition from a label to another while changing the environment and store. The transition is bidirectional, so it describes both forward and backward execution. This is used in the rule for uncall, where the transition relation is used in the reverse order for executing the subroutine.

We use a (possibly subscripted) meta variable I to indicate an unspecified instruction (update or exchange), E to indicate an unspecified entry point, X to indicate an unspecified exit point and c to indicate an unspecified condition. Abusing notation, we use $\oplus$, $\odot$ and $\bowtie$ to represent both the syntactic and semantic versions of operators. We use the same rules for evaluating expressions and conditions, using 0 to represent false and any non-zero value to represent true.

Fig. 9

Semantics of RIL

Fig. 10

Grammar for a small functional language

Appendix: Compilation Scheme

For reasons of space, we show a compilation scheme for a subset of the language we have used for examples. This is intended to show that the memory manager presented in this paper is suitable for functional languages.

A grammar for the language is found in Fig. 10. We use the following restrictions, that we assume hold, to ensure reversibility:

• If a function definition has more than one rule, these cannot have overlapping patterns, neither for inputs or outputs.

• A variable defined in a pattern must be used exactly once in a pattern. Patterns that define variables are patterns for arguments in a function definition or patterns for results of function calls in let-definitions. Patterns that use variables are patterns for function results or for arguments to function calls in let-definitions.

To allow multiple uses of values, we use a special function copy that takes a value as input and returns a cons-pair with two copies of that value. In reverse, it takes a cons-pair of two identical values and returns one of these. It is undefined if the argument is not a pair of two identical values. A compiler can insert such calls when a variable is used multiple times.

A function takes a single argument and returns a single result. A let-definition of the form let $~f~p_1~=~p_2~$ in represents calling f backwards with $p_2$ as argument and $p_1$ as result. A similar notation is used in RFUN2 [17] and Theseus [10].

In the compiled code, the argument is passed in the variable A, and the result is passed in R. A constant is any pattern not containing variables. Symbols and numbers are represented as number constants, for example, the empty list [] is represented by the value 2 and the integer 3 is represented as the value 7 (i.e., 3<<1+1). More complex constants are evaluated into named variables in an initialisation function (such as nilnil as in Fig. 8). A pattern of the form x  !=  p is a guard: It matches any value that does not match the pattern p and binds that value to x. No variables in p are ever bound, so they cannot be used in the rule. For example, the pattern x != y :: z matches when the value is not a pair, and binds x to that value if so. In no cases are y or z bound.

Fig. 11

Compilation scheme for functions

Fig. 12

Compilation scheme for let-definitions

The functions in a program are compiled independently of each other. It is assumed that names in the program are renamed so they do not clash with names used by the memory manager or the compiler. Compilation schemes for functions, patterns, and let-definitions are shown in Figs. 11, 12, and 13. We use $\overline{c}$ to represent the inversion of the code c, as described in Sect. 3.4. As this is a local inversion, call is inverted to uncall and vice versa.

Note that the code in Fig. 8 does not quite follow the compilation scheme presented here, as many simplifications are made to fit the code on one page.

Fig. 13

Compilation scheme for patterns