a type system for borrowing permissions
DESCRIPTION
A Type System for Borrowing Permissions. Karl Naden, Rob Bocchino Jonathan Aldrich, Kevin Bierhoff POPL – January 27, 2012. School of Computer Science. Aliasing. Trade off of aliases Pros: flexibility, performance, fields Cons: Global effects difficult to reason about Example : Files. - PowerPoint PPT PresentationTRANSCRIPT
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 immutablec: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?