A Type System for Borrowing Permissions Karl Naden, Rob Bocchino Jonathan Aldrich, Kevin Bierhoff POPL – January 27, 2012 School of Computer Science

OpenFile xy 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 xy ClosedFile Illegal Access

OpenFile x:uniquey: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 unique 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 = 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 car roger.borrow(theCar); //borrow(local immutable) josh.sell(theCar, sarah) //sell(unique >> none, --) theCar:unique CodeTracked Permissions theCar:none Internal Permission Only Typechecks!

Incorrect Use 12 class CarThief extends Person { borrow(local immutable Car c) { c.makeKey() //makeKey() immutable } } CodeTracked 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 } } CodeTracked Permissions c:local immutablec:borrow(immutable,1) a:local immutable a:borrow(immutable,1) c:borrow(immutable,1) a:local immutable c:borrow(immutable,2) c:borrow(immutable,1) a:local immutable c:local immutable Typechecks!

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 Garageg:? 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 Garageg:(unique;p1:none) Type Error – g not packed g:(unique;p1:none) CodeTracked 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 CodeTracked Permissions g:(local immutable; p2:borrow(unique,1)) c:local immutable c:borrow(immutable,1) g:(local immutable; p2:borrow(unique,1)) c:local immutable g: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?