A Type System for Borrowing Permissions

Karl Naden, Rob BocchinoJonathan Aldrich, Kevin Bierhoff

POPL – January 27, 2012

School of Computer Science

OpenFile

x y

OpenFile

Aliasing

2

File x=…;File y=…;…x.close();…y.read(); ClosedFile

• Trade off of aliases– Pros: flexibility, performance, fields– Cons: Global effects difficult to reason about

• Example : Files

x y

ClosedFileIllegal Access

OpenFile

x:unique y:immutable

OpenFile

Access Permissions

3

unique File x=…;immutable File y=…;…x.close(); //close() unique…y.read(); //read() immutable ClosedFile

Safe

• Permission associated with each reference, indicating– Actions that can be taken with this reference– How many aliases might exist and their abilities

• Examples:– unique (linear/affine) – full access, no other aliases– immutable (non-linear) – non-modifying access, all other aliases non-modifying– shared (non-linear) – many aliases with modifying access

Permission Use Patterns• Borrowing

– Make a unique reference temporarily immutable– must track aliases to ensure none leftover when regain unique

• Fields• Use permissions to objects in fields

4

uniqueimmutable

immutable

…

unique

immutable

Both essential for use in practice!

Existing Solutions• Borrowing

– Characterize Heap Explicitly• Alias Types• Shape Analysis

– Fractional Permissions

– Both powerful, but difficult to reason about

• Fields– Swap (awkward) – Explicit unpacking annotations (flexible but heavyweight)

5

createIterator(immutable(x) >> immutable(x/2) Collection) {…}

Iterator it<c,immutable(.5)> = createIterator(c)

Contributions• Local permissions:

– Permission-based borrowing• No artificial arithmetic• No explicit heap model

– Type system to track permission flow• Counting of aliases under the covers

• Field Unpacking– Standard aliasing semantics– No additional syntax for field reads or assignments– Implicit unpacking handled by type system

6

Outline• Introduction to local Permissions

– Using– Checking

• Unpacking Fields• In the paper and TR• Conclusion

7

Outline• Introduction to local Permissions

– Using– Checking

• Unpacking Fields• In the paper and TR• Conclusion

8

Local Permissions

9

• Design criteria: Permission-based borrowing– Extend ideas of permissions: Abilities and Guarantees

• Local modifier to non-linear permissions– Same access and aliasing guarantees– Additional promise to only create temporary aliases

• Cannot store to a field

Owning and Borrowing a Car

10

• Ownership– Owner has unique permission– Selling transfers the unique

permission to another Person

• Borrowing– A person without a car can

temporarily borrow one taking a local immutable permission

• Use– Owners or borrowers can drive a

car (local immutable)– Duplicating a key creates an

immutable reference

class Person { borrow(local immutable Car c) {…} sell(unique >> none Car c, Person p) {…}}class Car { drive() local immutable {…} newKey() immutable {…}}

theCar:uniquetheCar:borrow(unique,1)

Borrowing Solution

11

Person roger = new Person;Person sarah = new Person;Person josh = new Person;unique Car theCar = new Car();

//josh’s carroger.borrow(theCar);

//borrow(local immutable)

josh.sell(theCar, sarah)//sell(unique >> none, --)

theCar:unique

Code Tracked Permissions

theCar:none

Internal Permission Only

Typechecks!

Incorrect Use

12

class CarThief extends Person { borrow(local immutable Car c) {

c.makeKey() //makeKey() immutable

}}

Code Tracked Permissions

c:local immutable

• immutable a stronger permission than local immutable– Cannot get an immutable from a local immutable

TypeError – Not enough Permission!

Correct Use

13

class Inconsiderate extends Person { borrow(local immutable Car c) { local immutable Car a = c; a.drive()//drive() local immutable this.sister.borrow(c) //borrow(local immutable) //local variable ‘a’ leaves scope }}

Code Tracked Permissions

c:local immutable

c:borrow(immutable,1)

a:local immutablea:borrow(immutable,1)c:borrow(immutable,1)

a:local immutable

c:borrow(immutable,2)

c:borrow(immutable,1)

a:local immutable

c:local immutableTypechecks!

Benefits of Local

14

• Programmer can keep thinking in terms of permissions– What kind of permission should be provided?

• Do permanent aliases need to be created?

• Simple– No fractions or arithmetic

• Tracking handled by system, not by programmer– No need to try and visualize/characterize the heap

Outline• Introduction to local Permissions

– Using– Checking

• Unpacking Fields• In the paper and TR• Conclusion

15

Fields

16

• Motivation– Using fields creates aliases!– Changes permission of references in fields

• Design criteria– Standard aliasing semantics– No extra syntax

• Implicit unpacking– Read and assign as normal– Type system tracks unpacking of fields individually

Fields

17

• What is the type of ‘g’ after it no longer has a unique permission in the field ‘p1’?– Still unique, – but not a complete Garage– What about the Car in field ‘p2’?

class Garage { unique Car p1; unique Car p2;}josh.sell(g.p1,sarah);

//sell(unique>>none,--)

g:unique Garage

g:?

Tracked Permissions

Unpacking Unique

18

josh.sell(g.p1,sarah); //sell(unique>>none,--)

g.p2.drive(); //drive() local immutable

g.p1 = new Car;

me.sellG(g,sarah); //sellG(unique>>none garage,

Person)

g:unique Garage

g:(unique;p1:none)

Type Error – g not packed

g:(unique;p1:none)

Code Tracked Permissions

g:unique

g:(unique;p1:none)

g:(unique;p1:none, p2:borrow(unique,1))

Typechecks!

g:none

Internal Only

Unpacking local

19

borrowGarage (local immutable Garage g) { local immutable Car c = g.p2;

c.drive(); //drive() local immutable

// c goes out of scope}

g:local immutable

Code Tracked Permissions

g:(local immutable; p2:borrow(unique,1))c:local immutablec:borrow(immutable,1)

g:(local immutable; p2:borrow(unique,1))c:local immutableg:local immutable

Typechecks!

Benefits of Implicit Unpacking

20

• Simple– No extra annotations– Natural aliasing semantics

Outline• Introduction to local Permissions

– Using– Checking

• Unpacking Fields• In the paper and TR• Conclusion

21

More in the Paper

22

• Complete System– Shared permissions– Control flow (match)

• Formal System– typing rules

• Soundness claims– Proof in the TR

• Issues with published system– Several inconsistencies found post-publication– TR details problems and includes updated rules and proof

Conclusion

23

• Contributions– Local permissions support borrowing in consistent simple manner

• No complex fractions• No heap visualizations

– Fields unpacked implicitly• Normal aliasing semantics• No extra annotations

– Sound type system tracks access permissions• Restore unique permission after borrowing• Tracks unpacked fields

• Questions?