Typed Memory Managementin a

Calculus of Capabilities

David Walker

(with Karl Crary and Greg Morrisett)

PoPL '99 David Walker, Cornell University 2

The TAL Project

Verify

GC

SystemInterface

LinkCompile

Code Types

Code Types

Code TypesCode

PoPL '99 David Walker, Cornell University 3

TAL Goals

• Security– reduce the trusted computing base

• Software Engineering– eliminate dynamic failure modes; use static checking

• Flexibility– give programmers control over low-level details – admit varying compilation strategies

PoPL '99 David Walker, Cornell University 4

TAL Memory Management

• Garbage Collection: behind-the-scenes cleanup

• Problems:– Complex code in the trusted computing base– Under-specified invariants link client and collector

(type tags, pointer restrictions, etc)– No control over memory management decisions

• Java, PCC, SPIN, ECC also use GC

PoPL '99 David Walker, Cornell University 5

Regions (Tofte and Talpin)

• Explicit but provably safe deallocation• Static error checking• Simple, constant-time routines

• Regions are allocated on a stack• Objects are allocated into regions• Topmost regions are deallocated

PoPL '99 David Walker, Cornell University 6

Towards Region-Based TAL

letrgn in f ( )end;...more code

regionlifetime

High-level Code: Low-level Code:

• Region lifetimes are unclear in low-level code• Optimizations break the LIFO allocation structure

CALL SITE: newrgn ; mov r, RET; jmp f;

RET: freergn ; more code

PoPL '99 David Walker, Cornell University 7

Contributions

• The Capability Calculus: – A new statically-typed region-based

intermediate language

• A syntactic proof of soundness

• Typed Assembly Language with primitives for safely allocating and freeing regions

• A translation from a variant of the Tofte-Talpin framework

PoPL '99 David Walker, Cornell University 8

A New Perspective

Static Capabilities 2

1

2 x1

Regions

2

Freeregion 1

x1

2

PoPL '99 David Walker, Cornell University 9

The Capability Calculus

• A continuation-passing style language:

e ::= let d in e | v[1,...,m](v1,...,vn) | ...

• With declarations for separate allocation and deallocation of regions:

d ::= newrgn | freergn | x=v@ | ...

PoPL '99 David Walker, Cornell University 10

Types

• Types: ints, tuples, polymorphic functions– <1,...,n> @ [].(C,1,...,n) -> 0 @

• Capabilities: the collection of regions currently accessible– C ::= Ø | | {} | C1 C2 (first try)

PoPL '99 David Walker, Cornell University 11

An Example

; Initial Capability C = Ølet newrgn 1

newrgn 2

x = <2,3>@1

y = <x,4>@2

freergn 1

z = 1 y

w = 1 z

in ...

; C = {1}

; C = {1,2}

; 1 ok

; 2 ok

; C = {2}

; 2 ok

; 1 not ok!

2 34y

2 1

4y

2

z

PoPL '99 David Walker, Cornell University 12

A Second Example

fun f[1,2]({1,2}, x : <int>@2, ...).

let freergn 1

z = 1 x

in ...

; C = {}f [,](<3>@, ...)

; C = {1,2}

; C = {2}

; 2 ok

; instantiation causes 1 to alias 2:

PoPL '99 David Walker, Cornell University 13

Aliasing

• Safe revocation requires that all copies of a capability be deleted

• Type instantiation creates aliases

• No local analysis can detect these aliases

PoPL '99 David Walker, Cornell University 14

Previous Work

• Linear Type Systems (Girard,Wadler,...)

• Syntactic Control of Interference (Reynolds)

• These systems prevent aliasing; we need to track aliasing.

PoPL '99 David Walker, Cornell University 15

Alias Tracking

• New Capabilities: {1} and {+}

• {1} indicates is unique

• {+} indicates is duplicatable

• {+} = {+,+} but {1} {1,1}

• {+,+} is good but {1,1} is bad

PoPL '99 David Walker, Cornell University 16

Safe Deallocation

; Capability = Cnewrgn ; Capability = C {1}

; Capability = C {1}freergn ; Capability = C

PoPL '99 David Walker, Cornell University 17

An Example Revisited

fun f[1,2]({11,2

1}, x : <int>@2, ...).

let freergn 1

z = 1 x

in ...

; C = {}f [,](<3>@, ...)

; C = {31,4

1}

f [3,4](<3>@4, …)

; C = {11,2

1}

; 1 unique, C = {21}

; 2 ok

; No: {1} {1,1}

; Yes!

PoPL '99 David Walker, Cornell University 18

Subcapabilities

• Duplicatable capabilities: necessary to make functions sufficiently polymorphic

• Unique capabilities provide all of the privileges of duplicatable capabilities:

{1} {+}

PoPL '99 David Walker, Cornell University 19

Using Subcapabilities

fun g[,]({+,

+}, x: <int>@, y: <int>@, ...). … ; neither region is deallocated

; Current Capability = {1}let x = <3>@ing [,](x, x, ...) ; ok: {1} {+} = {+, +}

PoPL '99 David Walker, Cornell University 20

Final Pieces

• Solution: bounded quantification

allocate regions ; grants unique capabilities... |jump to f ; lose some privileges: {1} {+} | ...deallocate regions ; requires unique capabilities, ; but we’ve given them up ...

PoPL '99 David Walker, Cornell University 21

BQ Example

let newrgn ; capability C = {1} ... ; f: [, , {

+, +}].

(, ..., (, ...) -> 0 @ ) -> 0 @ ... ; cont: ({1}, ...) -> 0 @ , frees region in f [, , {1}](..., cont) ; ok: {1} {+} = {+, +}

PoPL '99 David Walker, Cornell University 22

Related Work

• Region inference – Tofte and Talpin (PoPL ‘94)– Aiken et al. (PoPL ‘95)– Birkedal et al. (PoPL ‘96)– ML Kit with regions

• Effect Systems, Monads

• Linear Types, Syntactic Control of Interference

PoPL '99 David Walker, Cornell University 23

Summary

• Capabilities govern access to sensitive data

• We control capability aliasing by tracking uniqueness information

• The result: flexible and provably safe deallocation