Typed Memory Management in a Calculus of Capabilities David Walker (with Karl Crary and Greg Morrisett)
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