A Type System for Safe Memory Management
and its Proof of Correctness
?
(Technical report SIC-5-08)
Manuel Montenegro Ricardo Pe˜na Clara Segura
montenegro@fdi.ucm.es {ricardo,csegura}@sip.ucm.es
Universidad Complutense de Madrid, Spain
Abstract. We present a destruction-aware type system for the func-
tional language Safe, which is a first-order eager language with facilities
for programmer controlled destruction and copying of data structures.
It provides also regions, i.e. disjoint parts of the heap, where the pro-
gram allocates data structures. The runtime system does not need a
garbage collector and all allocation/deallocation actions are done in con-
stant time. This research is targeted to mobile code applications with
limited resources in a Proof Carrying Code framework.
The type system guarantees that, in spite of sharing and of the use of im-
plicit and explicit memory deallocation operations, well-typed programs
will be free of dangling pointers at runtime. We also prove its correctness
with respect to the operational semantics of the language.
1 Introduction
Most functional languages abstract the programmer from the memory manage-
ment done by programs at run time. The runtime support system usually allo-
cates fresh heap memory while program expressions are being evaluated as long
as there is enough free memory available. Should the memory be exhausted, the
garbage collector will copy the live part of the heap to a different space and will
consider the rest as free. This normally implies the suspension of program exe-
cution for some time. Occasionally, not enough free memory has been recovered
and the program simply aborts. This model is acceptable in most situations,
being its main advantage that programmers are not bored, and programs are
not obscured, with low level details about memory management. But, in some
other contexts, this scheme may not be acceptable:
1. The time delay introduced by garbage collection prevents the program from
providing an answer in a required reaction time.
2. Memory exhaustion abortion may provoke unacceptable personal or eco-
nomic damage to program users.
3. The programmer wishes to reason about memory consumption.
?
Work supported by the projects TIN2004-07943-C04, S-0505/TIC/0407 (PROME-
SAS) and the MEC FPU grant AP2006-02154.
On the other hand, many imperative languages offer low level mechanisms to
allocate and free heap memory. These mechanisms give programmers a complete
control over memory usage but are very error prone. Well known problems are
dangling references, undesired sharing with complex side effects, and polluting
memory with garbage.
In our functional language Safe, we have chosen a semi-explicit approach to
memory control in which programmers may cooperate with the memory man-
agement system by providing some information about the intended use of data
structures (in what follows, abbreviated as DS). For instance, they may indicate
that some particular DS will not be needed in the future and that it should be
destroyed by the runtime system and its memory recovered. Programmers may
also launch copies of a DS and control the degree of sharing between DSs. In
order to use these facilities in safe way, we have developed a type system which
guarantees that dangling pointers will never arise at runtime in the living heap.
The proposed approach overcomes the above mentioned shortcomings: (1)
A garbage collector is not needed because the heap is structured into disjoint
regions which are dynamically allocated and deallocated; (2) as we will see below,
we will be able to reason about memory consumption. It will even be possible
to show that an algorithm runs in constant heap space, independently of input
size; and (3), as an ultimate goal regions will allow us to statically infer sizes for
them and eventually an upper bound to the memory consumed by the program.
The language is targeted to mobile code applications with limited resources
in a Proof Carrying Code framework [Nec97,NL98]. The final aim is to endow
programs with formal certificates proving the above properties. This aspect, as
well as region size inference, are however beyond the scope of the current paper.
The Safe language and a sharing analysis for it were published in [PSM07a].
The use of regions in functional languages to avoid garbage collection is not
new. Tofte and Talpin [TT97] introduced in ML-Kit —a variant of ML— the
use of nested regions by means of a letregion construct. A lot of work has been
done on this system [AFL95,BTV96,HMN01,TBE
+
06]. Their main contribution
is a region inference algorithm adding region annotations at the intermediate
language level. Hughes and Pareto [HP99] incorporate regions in Embedded-
ML. This language uses a sized-types system in which the programmer annotates
heap and stack sizes and these annotations can be type-checked. So, regions can
be proved to be bounded. A small difference with these approaches is that,
in Safe, region allocation and deallocation are synchronized with function calls
instead of being introduced by a special language construct. A more relevant
difference is that Safe has an additional mechanism allowing the programmer to
selectively destroy data structures inside a region. More recently, Hofmann and
Jost [HJ03] have developed a type system to infer heap consumption. Theirs is
also a first-order eager functional language with a construct match
0
that destroys
constructor cells. Its operational behaviour is similar to that of Safe case!. The
main difference is that they lack a compile time analysis guaranteeing the safe use
of this dangerous feature. Also, their language do not use regions. In [PSM07a]
a more detailed comparison with all these works can be found.
Our safety type system has some characteristics of linear types (see [Wad90]
as a basic reference). A number of variants of linear types have been developed
2
for years for coping with the related problems of achieving safe updates in place
in functional languages [Ode92] or detecting program sites where values could be
safely deallocated [Kob99]. The work closest to our system is [AH02], which pro-
poses a type system for a language explicitly reusing heap cells. They prove that
well-typed programs can be safely translated into an imperative language with
an explicit deallocation/reusing mechanism. We summarise here the differences
and similarities with our work.
There are non-essential differences such as: (1) they only admit algorithms
running in constant heap space, i.e. for each allocation there must exist a previous
deallocation; (2) they use at the source level an explicit parameter d representing
a pointer to the cell being reused; and (3) they distinguish two different carte-
sian products depending on whether there is sharing or not between the tuple
components. But, in our view, the following more essential differences makes our
type-system more powerful than theirs:
1. Their uses 2 and 3 (read-only and shared, or just read-only) could be roughly
assimilated to our use s (read-only), and their use 1 (destructive), to our use
d (condemned), both defined in Section 4. We add a third use r (in-danger)
arising from a sharing analysis based on abstract interpretation [PSM07a].
This use allows us to know more precisely which variables are in danger when
some other one is destroyed.
2. Their uses form a total order 1 < 2 < 3. A type assumption can always
be worsened without destroying the well-typedness. Our marks s, r, d do not
form a total order. Only in some expressions (case and x@r) we allow the
partial order s ≤ r and s ≤ d. It is not clear whether that order gives or not
more power to the system. In principle it will allow diferent uses of a variable
in different branches of a conditional being the use of the whole conditional
the worst one. For the moment our system does not allow this.
3. Their system forbids non-linear applications such as f (x, x). We allow them
for s-type arguments.
4. Our typing rules for let x
1
= e
1
in e
2
allow more use combinations than
theirs. Let i ∈ {1, 2, 3} the use assigned to x
1
, j the use of a variable z in e
1
,
and k the use of the variable z in e
2
. We allow the following combinations
(i, j, k) that they forbid: (1, 2, 2), (1, 2, 3), (2, 2, 2), (2, 2, 3). The deep reason
is our more precise sharing information and the new in-danger type.
5. They need explicit declaration of uses while we infer them [PSM07b].
The plan of the paper is as follows; In Section 2 we informally introduce
and motivate the language features. Section 3 formally defines its operational
semantics. The kernel of the paper are sections 4 and 5 where respectively the
destruction-aware type system is presented and proved correct. By lack of space,
the detailed proofs are included in a separate appendix. Finally, Section 6 shows
examples of successful type derivations and Section 7 concludes.
2 Summary of Safe
Safe is a first-order polymorphic functional language similar to (first-order)
Haskell or ML with some facilities to manage memory. The memory model is
3
based in heap regions where data structures are built. However, in Full-Safe in
which programs are written, regions are implicit. These are inferred when Full-
Safe is desugared into Core-Safe, where they are explicit. As all the analyses
mentioned in this paper happen at Core-Safe level, later in this section we will
describe it in detail.
The allocation and deallocation of regions is bound to function calls: a work-
ing region is allocated when entering the call and deallocated when exiting it.
Inside the function, data structures may be built but they can also be destroyed
by using a destructive pattern matching denoted by ! or a case! expression,
which deallocates the cell corresponding to the outermost constructor. Using re-
cursion the recursive spine of the whole data structure may be deallocated. We
say that it is condemned. As an example, we show an append function destroying
the first list’s spine, while keeping its elements in order to build the result:
concatD []! ys = ys
concatD (x:xs)! ys = x : concatD xs ys
As a consequence, the concatenation needs constant heap space, while the usual
version needs linear heap space. The fact that the first list is lost is reflected in
the type of the function: concatD :: [a]! -> [a] -> [a].
The data structures which are not part of function’s result are built in the lo-
cal working region, which we call self, and they die when the function terminates.
As an example we show a destructive version of the treesort algorithm:
treesortD :: [Int]! -> [Int]
treesortD xs = inorder (mkTreeD xs)
First, the original list xs is used to build a search tree by applying function
mkTreeD (defined below). This tree is then traversed in inorder to produce the
sorted list. The tree is not part of the result of the function, so it will be built
in the working region and will die when the treesortD function returns (in
Core-Safe where regions are explicit this will be apparent). The original list is
destroyed and the destructive appending function is used in the traversal so that
constant heap space is consumed.
Function mkTreeD inserts each element of the list in the binary search tree.
mkTreeD :: [Int]! -> BSTree Int
mkTreeD []! = Empty
mkTreeD (x:xs)! = insertD x (mkTreeD xs)
The function insertD is the destructive version of insertion in a binary search
tree. Then mkTreeD exactly consumes in the heap the space occupied by the list.
Otherwise, in the worst case the function would consume quadratic heap space.
insertD :: Int -> BSTree Int! -> BSTree Int
insertD x Empty! = Node Empty x Empty
insertD x (Node lt y rt)! | x == y = Node lt! y rt!
| x > y = Node lt! y (insertD x rt)
| x < y = Node (insertD x lt) y rt!
4
prog → dec
1
; . . . ; dec
n
; e
dec → f x
i
n
@ r
j
l
= e {recursive, polymorphic function}
e → a {atom: literal c or variable x}
| x@r {copy}
| x! {reuse}
| f a
i
n
@ r
j
l
{function application}
| let x
1
= be in e {non-recursive, monomorphic}
| case x of alt
i
n
{read-only case}
| case! x of alt
i
n
{destructive case}
alt → C x
i
n
→ e
be → C a
i
n
@ r {constructor application}
| e
Fig. 1. Core-Safe language definition
Notice in the first guard, that the cell just destroyed must be built again. When a
data structure is condemned its recursive children may subsequently be destroyed
or they may be reused as part of the result of the function. We denote the latter
with a !, as shown in this function insertD. This is due to safety reasons: a
condemned data structure cannot be returned as the result of a function, as
it potentially may contain dangling pointers. Reusing turns a condemned data
structure into a safe one. The original reference is not accessible any more. The
type system shown in this paper copes with all these features to avoid dangling
pointers. So, in the example lt and rt are condemned and they must be reused
in order to be part of the result.
Data structures may also be copied using @ notation. Only the recursive
spine of the structure is copied, while the elements are shared with the old one.
This is useful when we want non-destructive versions of functions based on the
destructive ones. For example, we can define treesort xs = treesortD (xs@).
In Fig. 1 we show the syntax of Core-Safe. A program prog is a sequence of
possibly recursive polymorphic function definitions followed by a main expression
e, calling them, whose value is the program result. The abbreviation x
i
n
stands
for x
1
· · · x
n
. Destructive pattern matching is desugared into case! expressions.
Constructions are only allowed in let bindings, and atoms are used in function
applications, case/case! discriminant, copy and reuse. Regions are explicit in
constructor application and the copy expression. Function definitions building
a new data structure will have additional parameters r
j
, which are the output
regions, where the resulting data structure is to be constructed. In the right hand
side expression only the r
j
and its own working region, written self , may be used.
Consequently, as we will see later, functional types include region parameter
types.
Polymorphic algebraic data types definitions are defined separately through
data declarations. Algebraic types declarations have additional parameters in-
dicating the regions where the constructed values of that type are allocated. For
example, trees are represented as follows:
data Tree a @ rho = Empty@rho | Node (Tree a@rho) a (Tree a@rho) @ rho
There may be several region parameters when nested types are used: different
components of the data structure may live in different regions. In that case the
5